Known Issues for Block Volume

Known issues have been identified in Block Volume.

Cross-region replication not supported for volumes encrypted with customer-managed keys

Details: When you try to enable cross-region replication for a volume configured to use a Vault encryption key, the following error message occurs: Edit Volume Error: You cannot enable cross-region replication for volume <volume_ID> as it uses a Vault encryption key.
Workaround: We're working on a resolution. Cross-region replication isn't supported for volumes encrypted with a customer-managed key. As a workaround to enable replication, unassign the Vault encryption key from the volume. In this scenario, the volume is encrypted with an Oracle-managed key.

Paravirtualized volume attachment not multipath-enabled after instance is resized

Details: To achieve the optimal performance level for volumes configured for ultra high performance, the volume attachment must be multipath-enabled. Multipath-enabled attachments to VM instances are only supported for instances based on shapes with 16 or greater OCPUs.; If you have an instance with fewer than 16 OCPUs, you can resize it so that it has 16 or more OCPUs to support multipath-enabled attachments. This step doesn't work for instances where the original number of OCPUs was less than 8 and the volume attachment is paravirtualized. In this scenario, after the volume is detached and reattached, the volume attachment still isn't multipath-enabled even though the instance now supports multipath-enabled attachments.
Workaround: As a workaround, we recommend that you create a new instance based on a shape with 16 or more OCPUs, and then attach the volume to the new instance.

Attaching the maximum number of block volumes to smaller VM.Standard.A1.Flex instances might fail

Details: When you attempt to attach the maximum number of block volumes to a smaller VM.Standard.A1.Flex instance, the volumes might fail to attach. This failure happens because of limitations with the underlying physical host configuration.
Workaround: We're working on a resolution. As a workaround, we recommend that you increase the size of the VM by resizing the VM, and then try attaching the volumes again.

Vault encryption keys not copied to destination region for scheduled cross region backup copies

Details: When you schedule volume and volume group backups using a backup policy that is enabled for cross-region copy for volumes that are encrypted using Vault service encryption keys, the encryption keys are not copied with the volume backup to the destination region. The volume backup copies in the destination region are instead encrypted using Oracle-provided keys.
Workaround: We're working on a resolution. As a workaround, you can manually copy volume backups and volume group backups across regions, either manually or using a script, and specify the key management key ID in the target region for the copy operation. For more information about manual cross region copy, see Copying a Volume Backup Between Regions.

Attaching a Windows boot volume as a data volume to another instance fails

Details

When you attach a Windows boot volume as a data volume to another instance, when you try to connect to the volume using the steps described in Connecting to a Block Volume the volume fails to attach and you might see the following error:

Connect-IscsiTarget : The target has already been logged in via an iSCSI session.

Workaround

You need to append the following to the Connect-IscsiTarget command copied from the Console:

-IsMultipathEnabled $True

bootVolumeSizeInGBs attribute is null

Details: When calling GetInstance, the bootVolumeSizeInGBs attribute of InstanceSourceViaImageDetails is null.
Workaround: We're working on a resolution. To work around this issue, call GetBootVolume, and use the sizeInGBs attribute of BootVolume.