FAQs for Block Storage for VPC

How does Block Storage for VPC prevent a single point of failure? What mechanism assures data durability?

Block Storage for VPC volume data is stored redundantly across multiple physical disks in an Availability Zone to prevent data loss due to failure of any single component.

How are volumes created and attached to an instance?

When you create a virtual server instance, you can create a Block Storage for VPC volume that is attached to that instance. You can also create stand-alone volumes and later attach them to your instances.

How many instances can share a provisioned Block Storage for VPC volume?

A Block Storage for VPC volume can be attached to only one instance at a time. Instances cannot share a volume.

How many Block Storage for VPC secondary data volumes can be attached to an instance?

You can create 12 Block Storage for VPC data volumes per instance, plus the boot volume.

How am I charged for usage?

The cost for Block Storage for VPC is calculated based on GiB capacity that is stored per month, unless the duration is less than one month. The volume exists on the account until you delete the volume or you reach the end of a billing cycle, whichever comes first.

Pricing is also affected when you expand volume capacity or adjust IOPS by specifying a different IOPS profile. For example, expanding volume capacity increases costs, and changing an IOPS profile from a 5-IOPS/GB tier to a 3-IOPS/GB tier decreases the monthly and hourly rate. Billing for an updated volume is automatically updated to add the prorated difference of the new price to the current billing cycle. The new full amount is then billed in the next billing cycle.

You can use the Cost estimator in IBM Cloud console to see how changes in capacity and IOPS affect the cost. For more information, see Estimating your costs.

Is storage capacity measured in GB or GiB?

One confusing aspect of storage is the units that storage capacity and usage are reported in. Sometime GB is really gigabytes (base-10) and sometimes GB represents gibibytes (base-2) which should be abbreviated as GiB.

Humans usually think and calculate numbers in the decimal (base-10) system. In our documentation, we refer to storage capacity by using the unit GB (Gigabytes) to align with the industry standard terminology. In the UI, CLI, API, and Terraform, you see the unit GB used and displayed when you query the capacity. When you want to order a 4-TB volume, you enter 4,000 GB in your provisioning request.

However, computers operate in binary, so it makes more sense to represent some resources like memory address spaces in base-2. Since 1984, computer file systems show sizes in base-2 to go along with the memory. Back then, available storage devices were smaller, and the size difference between the binary and decimal units was negligible. Now that the available storage systems are considerably larger this unit difference is causing confusion.

The difference between GB and GiB lies in their numerical representation:

• GB (Gigabyte) is a decimal unit, where 1 GB equals 1,000,000,000 bytes. When you convert GB to TB, you use 1000 as the multiplier.
• GiB (Gibibyte), is a binary unit, where 1 GiB equals 1,073,741,824 bytes. When you convert GiB to TiB, you use 1024 as the multiplier.

The following table shows the same number of bytes expressed in decimal and binary units.

The storage system uses base-2 units for volume allocation. So if your volume is provisioned as 4,000 GB, that's really 4,000 GiB or 4,294,967,296,000 bytes of storage space. The provisioned volume size is actually larger than 4 TB. However, your operating system might display the storage size as 3.9 T because it uses base-2 conversion and the T stands for TiB, not TB.

Why does the available capacity that I see in my OS not match the capacity that I provisioned?

One of the reasons can be that your operating system uses base-2 conversion. For example, when you provision a 4000 GB volume on the UI, the storage system reserves a 4,000 GiB volume or 4,294,967,296,000 bytes of storage space for you. The provisioned volume size is larger than 4 TB. However, your operating system might display the storage size as 3.9 T because it uses base-2 conversion and the T stands for TiB, not TB.

Second, partitioning your Block Storage and creating a file system on it reduces available storage space. The amount by which formatting reduces space varies depending upon the type of formatting that is used and the amount and size of the various files on the system.

Take the volume docs-block-test3 as an example. We specified 1200 GB during provisioning and when you list the details in the CLI, you can see that it has the capacity of 1200.

$ ibmcloud is volume r006-6afe1361-b592-45ab-b23b-6cca9982e371
Getting volume r006-6afe1361-b592-45ab-b23b-6cca9982e371 under account Test Account as user test.user@ibm.com...

ID                                     r006-6afe1361-b592-45ab-b23b-6cca9982e371
Name                                   docs-block-test3
CRN                                    crn:v1:bluemix:public:is:us-south-2:a/1234567::volume:r006-6afe1361-b592-45ab-b23b-6cca9982e371
Status                                 available
Attachment state                       attached
Capacity                               1200
IOPS                                   3600
Bandwidth(Mbps)                        471
Profile                                general-purpose
Encryption key                         -
Encryption                             provider_managed
Resource group                         defaults
Created                                2023-08-24T02:32:40+00:00
Zone                                   us-south-2
Health State                           ok
Volume Attachment Instance Reference   Attachment type   Instance ID                                 Instance name        Auto delete   Attachment ID                               Attachment name
                                       data              0727_e99798c7-9783-4f92-8207-96af48561454   docs-demo-instance   false         0727-bc38ec2b-a566-412f-8f76-8eefe5fc9f2c   untaken-senior-coronary-accurate

Active                                 true
Adjustable IOPS                        false
Busy                                   false
Tags                                   dev:test

When you list your storage devices from your server's command line, you can see the same volume as vdc with a size of 1.2T. The T stands for tebibyte, a base-2 unit that equals 2⁴⁰.

[root@docs-demo-instance ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    253:0    0  100G  0 disk
├─vda1 253:1    0  200M  0 part /boot/efi
└─vda2 253:2    0 99.8G  0 part /
vdb    253:16   0 69.9G  0 disk
vdc    253:32   0  1.2T  0 disk /myvolumedir
vdd    253:48   0  370K  0 disk
vde    253:64   0   44K  0 disk

The same vdc drive shows 1181679068 K available capacity when it is formatted with an ext4 file system. It's normal and expected.

[root@docs-demo-instance ~]# df -hk
Filesystem      1K-blocks    Used  Available Use% Mounted on
devtmpfs          3993976       0    3993976   0% /dev
tmpfs             4004356       0    4004356   0% /dev/shm
tmpfs             4004356   33316    3971040   1% /run
tmpfs             4004356       0    4004356   0% /sys/fs/cgroup
/dev/vda2       102877120 1182048   96446100   2% /
/dev/vda1          204580   11468     193112   6% /boot/efi
/dev/vdc       1238411052   72148 1181679068   1% /myvolumedir
tmpfs              800872       0     800872   0% /run/user/0

Are there limits on the number of volumes I can create?

You can create up to 300 total Block Storage for VPC volumes (data and boot) per account in a region. To increase this quota, open a support case and specify the zone where you need more volumes.

After a data volume is created with a specific capacity, can the capacity later be increased?

You can increase the capacity of data volumes that are attached to a virtual server instance. You can indicate capacity in GB increments up to 16,000 GB capacity, depending on your volume profile. For more information, see Increasing Block Storage for VPC volume capacity.

Can I increase the capacity of a boot volume?

Boot volume capacity can be increased during instance provisioning or later, by directly modifying the boot volume. This feature applies to instances that are created from stock or custom images. You can also specify a larger boot volume capacity when you create an instance template. The boot volume can't be unattached from an instance (that is, stored as a stand-alone data volume). For more information, see Increasing boot volume capacity.

Can I change boot volume capacity for an existing instance?

Yes, boot volume capacity can be increased for an existing instance. However, you increase capacity on the storage side. That is, by modifying the boot volume details. For example, in the UI, you'd select a boot volume from the list of Block Storage for VPC volumes and then resize the volume from the volume details page. For more information, see Increase boot volume capacity from the list of Block Storage for VPC volumes in the UI. You can also use the CLI or the API.

How many volumes can I provision on my account?

You can provision up to 300 Block Storage for VPC volumes per account in a region. You can request your quota to be increased by opening a support case and specifying the region where you need more volumes. For more information about preparing a support case when you're ordering Block Storage for VPC volumes or requesting an increase to your volume or capacity limits, see Managing volume count and capacity limits.

Can I set up shared storage in a multizone cluster?

In the IBM Cloud®, storage options are limited to an availability zone. Do not try to manage shared storage across multiple zones.

Instead, use an IBM Cloud® classic service option outside a VPC such as IBM Cloud® Object Storage or IBM® Cloudant® for IBM Cloud® if you must share your data across multiple zones and regions.

I have volumes on the Classic infrastructure. Can I port them to the VPC?

No. The VPC provides access to new availability zones in multi-zone regions. Compute, network, and storage resources are designed to function in the VPC.

What is an image from volume and how does it relate to Block Storage for VPC volumes?

With the image from volume feature, you can create a custom image directly from a Block Storage for VPC boot volume. Then, you can use the custom image to provision other virtual server instances. For more information, see About creating an image from a volume.

How is the boot disk created for an instance and how does it relate to the virtual machine image?

The boot volume is created when you provision a virtual server instance. The boot disk of an instance is a cloned image of the virtual machine image. For stock images, the boot volume capacity is 100 GB. If you are importing a custom image, the boot volume capacity can be 10 GB to 250 GB, depending on what the image requires. Images smaller than 10 GB are rounded up to 10 GB. The boot volume is deleted when you delete the instance to which it is attached.

When can I delete a Block Storage for VPC data volume?

You can delete a Block Storage for VPC data volume only when it isn't attached to a virtual server instance. Detach the volume before you delete it. Boot volumes are detached and deleted when the instance is deleted.

What happens to my data when I delete a Block Storage for VPC data volume?

When you delete a Block Storage for VPC volume, your data immediately becomes inaccessible. All pointers to the data on that volume are removed. The inaccessible data is eventually overwritten as new data is written to the data block. IBM guarantees that data deleted cannot be accessed and that deleted data is eventually overwritten. For more information, see Block Storage for VPC data eradication.

I have compliance requirements for data deletion. What can I do to ensure that my data is inaccessible?

IBM guarantees that your data is inaccessible on the physical disk and is eventually eradicated. If you have extra compliance requirements such as NIST 800-88 Guidelines for Media Sanitization, you must perform data sanitation procedures before you delete your volumes. For more information, see the NIST 800-88 Guidelines for Media Sanitation.

What rules apply to volume names and can I rename a volume later on?

Valid volume names can include a combination of lowercase alphanumeric characters (a-z, 0-9) and the hyphen (-), up to 63 characters. Volume names must begin with a lowercase letter and be unique across the entire VPC infrastructure.

You can change the name of an existing volume in the UI. For more information, see Managing Block Storage for VPC.

Does the volume need to be pre-warmed to achieve the expected throughput?

You do not have to pre-warm a volume. You can see the specified throughput immediately upon provisioning the volume when you create the volume from an image. You can experience degraded performance when you provision the volume by restoring a snapshot.

What is a Block Storage for VPC snapshot?

Snapshots are a point-in-time copy of your Block Storage for VPC boot or data volume that you manually create. The first snapshot is a full backup of the volume. Subsequent snapshots of the same volume capture only the changes since the last snapshot. For more information, see About Block Storage for VPC Snapshots for VPC.

What is a backup snapshot?

Backup snapshots, simply called "backups", are snapshots that are automatically created by the Backup for VPC service. For more information, see About Backup for VPC.

What can I do about data backups for disaster recovery?

Block Storage for VPC secures your data across redundant fault zones in your region. By using the backup service, 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. However, the backup service does not provide continual backup with automatic failover, and 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.

What is restoring a volume from a snapshot?

Restoring from a snapshot creates a new, fully provisioned boot or data volume. You can restore storage volumes during instance creation, instance modification, or when you provision a new stand-alone volume. For data volumes, you can also use the volumes API to create a data volume from a snapshot. For more information, see Restoring a volume from a snapshot.

For best performance, you can enable snapshots for fast restore. By using the fast restore feature, you can create a volume from a snapshot that is fully provisioned when the volume is created. For more information, see Snapshots fast restore.

Can I add tags to a volume?

Yes, you can add user tags and access management tags to your volumes. User tags are used by the backup service to automatically create backup snapshots of the volume. Access management tags help organize access to your Block Storage for VPC volumes. For more information, see Tags for Block Storage for VPC volumes.

What is IOPS and how do it relate to my Block Storage for VPC volume performance?

Input/output operations per second (IOPS) is used to measure the performance of your Block Storage for VPC volumes. A number of variables impact IOPS values, such as the balance of read/write operations, queue depth, and data block sizes. In general, the higher the IOPS of your Block Storage for VPC volumes, the better the performance. For more information about expected IOPS for Block Storage for VPC profiles, see Profiles. For more information about how block size affects performance, see Block Storage capacity and performance.

Is the allocated IOPS enforced by instance or by volume?

IOPS is enforced at the volume level.

What are IOPS profiles and how do they affect volume performance?

IOPS profiles define IOPS/GB performance for volumes of various capacities. You can select from three predefined IOPS tiers that offer reliable IOPS performance for your workload requirements. You can also define custom IOPS 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.

What happens when a volume is in a degraded health state?

Volume health state defines whether a volume is performing as expected, given its status. Volume health can be OK, degraded, inapplicable, or faulted, depending on what is happening. For example, a degraded status is displayed when a volume is being restored from a snapshot and the volume is not yet fully restored. For more information about volume health states, see Block Storage for VPC volume health states.

How secure is data in a Block Storage for VPC volume?

All Block Storage for VPC volumes are encrypted at rest with IBM-managed encryption. IBM-managed keys are generated and securely stored in a Block Storage for VPC vault that is backed by Consul and maintained by IBM Cloud® operations.

For more security, you can protect your data by using your own customer root keys (CRKs). You can import your root keys to, or create them in, a supported key management service (KMS). Your root keys are safely managed by the supported KMS, either Key Protect (FIPS 140-2 Level 3 compliance) or Hyper Protect Crypto Services. Both KMS solutions offer the highest level of security (FIPS 140-2 Level 4 compliance). Your key material is protected in transit and at rest.

For more information, see Supported key management services for customer-managed encryption. To learn how to configure customer-managed encryption, see Creating Block Storage for VPC volumes with customer-managed encryption.

You control access to your root keys stored in KMS instances within IBM Cloud® by using IBM Cloud Identity and Access Management (IAM). You grant access to the IBM Block Storage for VPC Service to use your keys. With the API, you can link a primary account that holds a root key to a secondary account, then use that key to encrypt new volumes in the secondary account. For more information, see Cross-account encryption for multitenant storage resources.

You can also revoke access at any time, for example, if you suspect your keys might be compromised. You can also disable or delete a root key, or temporarily revoke access to the key's associated data on the cloud. For more information, see Managing root keys.

What are the advantages of using customer-managed encryption over provider-managed encryption?

Customer-managed encryption encrypts your Block Storage for VPC volumes by using your own root keys. You have complete control over your data security and grant IBM access to use your root keys. For more information, see Advantages of customer-managed encryption.

What encryption technology is used for customer-managed encryption?

Virtual disk images for VPC use QEMU Copy On Write Version 2 (QCOW2) file format. LUKS encryption format secures the QCOW2 format files. IBM currently uses the AES-256 cipher suite and XTS cipher mode options with LUKS. This combination provides you a much greater level of security than AES-CBC, along with better management of passphrases for key rotation, and provides key replacement options in case your keys are compromised.

What are master encryption keys and how are they assigned to my Block Storage for VPC volumes?

Each volume is assigned a unique master encryption key, called a data encryption key or DEK, which is generated by the instance's host hypervisor. The master key for each Block Storage for VPC volume is encrypted with a unique KMS-generated LUKS passphrase, which is then encrypted by your customer root key (CRK) and stored in the KMS. Passphrases are AES-256 cipher keys, which means that they are 32 bytes long and not limited to printable characters. You can view the cloud resource name (CRN) for the CRK that is used to encrypt a volume. However, the CRK, LUKS passphrase, and the volume's master encryption key are never exposed. For more information about all the keys IBM VPC uses to secure your data, see IBM's encryption technology - How your data is secured.

I use customer-managed encryption for my volumes. What happens when I disable or delete my root key?

These actions are two separate actions. Disabling a root key in your KMS suspends its encryption and decryption operations, placing the key in a suspended state. Workloads continue to run in virtual server instances and boot volumes remain encrypted. Data volumes remain attached. However, if you power down the VM and then power it back on, any instances with encrypted boot volumes do not start. You can enable a root key in a suspended state and resume normal operations. For more information, see Disabling root keys.

Deleting a root key has greater consequences. Deleting a root key purges usage of the key for all resources in the VPC. By default, the KMS prevents you from deleting a root key that's actively protecting a resource. However, you can still force the deletion of a root key. You have limited time to restore a deleted root key that you imported to the KMS. For more information, see Deleting root keys.

Can I remove IAM authorization from Cloud Block Storage for VPC to the KMS and still delete my Block Storage for VPC volumes with customer-managed encryption?

If you remove IAM authorization before you delete your BYOK volume (or image), the delete operation completes without unregistering the root keys in the KMS instance. In other words, the root key remains registered for a resource that doesn't exist. Always delete a BYOK resource before you remove IAM authorization. For more information about safely removing service authorization, see Removing service authorization to a root key.

What can I do if my root key is compromised?

Independently back up your data. Then, delete the compromised root key and power down the instance with volumes that are encrypted with that key.

Also, consider setting up a key rotation policy that automatically rotates your keys based on a schedule. For more information, see Key rotation for VPC resources.

What is a key rotation?

For IBM Cloud VPC resources such as Block Storage for VPC volumes that are protected by your customer root key (CRK), you can rotate the root keys for extra security. When you rotate a root key by a schedule or on demand, the original key material is replaced. The old key remains active to decrypt existing volumes but can't be used to encrypt new volumes. For more information, see Key rotation for VPC resources.

How does key rotation work?

Customer-managed encrypted resources such as Block Storage for VPC volumes use your root key (CRK) as the root-of-trust key that encrypts a LUKS passphrase that encrypts a master key that's protecting the volume. You can import your CRK to a key management service (KMS) instance or instruct the KMS to generate one for you. Root keys are rotated in your KMS instance.

When you rotate a root key, a new version of the key is created by generating or importing new cryptographic key material. The old root key is retired, which means its key material remains available for decrypting existing volumes, but not available for encrypting new ones. New resources are protected by the latest key. For more information, see How key rotation works.

Am I charged for using customer-managed encryption?

You are not charged extra for creating volumes with customer-managed encryption. However, setting up a Key Protect or Hyper Protect Crypto Services instance to import, create, and manage your root keys is not without cost. Contact your IBM customer service representative for details.

What's the difference between using Key Protect as my KMS compared to Hyper Protect Crypto Services? When would I use one over the other?

Both key management systems provide you with complete control over your data, managed by your root keys. Key Protect is a multi-tenant KMS where you can import or create your root keys and securely manage them. Hyper Protect Crypto Services is a single-tenant KMS and hardware security module (HSM) that is controlled by you, which offers the highest level of security. For more information about these key management services, see Supported key management services for customer-managed encryption.

Can I convert my volume from provider-managed encryption to customer-managed encryption?

No, after you provision a volume and specify the encryption type, you can't change it.