Known issues

vcpu.manufacturer property returns an empty string value

Issue: When retrieving an instance, the value of the vcpu.manufacturer property is an empty string "".

The /instance_identity methods return incorrect HTTP status

Issue: When using a version query parameter of 2025-08-25 or earlier from bare metal servers, an incorrect HTTP response of 404 is returned for /instance_identity methods used to create an identity token, create an identity certificate, and create an IAM token. The behavior is correct when using a version query parameter of 2025-08-26 or later.

When using a beta version query parameter of 2025-07-14 or earlier from bare metal servers, an incorrect HTTP response of 404 is returned for all /instance_identity methods.

TDX virtual servers are supported in Washington DC (us-east) region only

Issue: All confidential computing profiles support both Intel® Software Guard Extensions (SGX) and Intel® Trusted Domain Extensions (TDX). When you use the API to list instance profiles, such as with GET /instance/profiles or GET /instance/profiles/{name}, the response indicates that all confidential computing profiles support SGX and TDX. However, TDX is currently available in the Washington DC (us-east) and Frankfurt (eu-de) regions only. If you want to create a virtual server instance with a confidential computing profile and TDX, you can create that virtual server instance only in the Washington DC (us-east) and Frankfurt (eu-de) regions. You can’t create a virtual server instance with TDX in any other region, including Dallas (us-south).

s390x profiles don't include 'values' property

Issue: When listing instance profiles or retrieving an instance profile, s390x instance profiles don't include the required values property in the confidential_compute_modes object. See s390x instance profiles for a complete list of profiles.

Checksum not available for some public images

Issue: When you use the API or CLI to list images, some public stock images might not include a checksum. The checksum is for informational purposes only for stock images. No fix is available.

A custom image that is created from a boot volume that was provisioned from an unencrypted image is bigger than the original image

Issue: If your custom image is not encrypted and the image is under 100 GB virtual disk size, deploying that image to an instance and creating a custom image from that instance's boot volume results in a minimum_provisioned_size of 100 GB. No fix is available.

Custom images in a private catalog known issue

Issue: If you imported one or more images into a virtual server image for VPC catalog product offering version and you edit that version, an extra version ending in "draft" is created. You can't provision an instance from this draft version. Draft versions might appear on the Virtual server instance creation page in the console or in the output of the CLI command ibmcloud is catalog-image-offering.

Default profile on POST /instances

Issue: When an instance is created without a profile specified by the user, it defaults to the bx2-2x8 profile instead of bxf-2x8.

iPXE network boot known timing issue

Issue: When you use the iPXE network boot on a Bare Metal Server on VPC, the network configuration process might still be incomplete when the iPXE script starts running. When this issue occurs, the DHCP command might fail or you might seem a timeout error. A fix for this issue is planned.

Workaround: From the VNC console, manually run the iPXE commands. Or, add the following to your iPXE script instead of the DHCP command.

  :retry_dhcp
  dhcp || goto retry_dhcp
  sleep 2

Issue: Flow log collectors are not integrated with bare metal servers. As a result, if you create a flow log collector for a VPC, traffic that flows to and from bare metal servers in that VPC aren't logged.

Issue: Network load balancers are not integrated with bare metal servers. As a result, if you create a network load balancer, you can't target a bare metal server as a load balancer pool member target.

Issue: You can't delete a subnet when you delete a bare metal server. Wait ~2 minutes after bare metal deletion before you delete the subnet.

Because all bare metal profiles are VMware® certified, the supported_image_flags image property and required_image_flags profile property that expressed this ability during the beta period are discontinued. These properties might still be visible to API and CLI consumers, but they aren't supported and must not be used. These properties will be removed entirely in a future release.

Fast restore snapshots with customer-managed encryption issue

Issue: When you restore a volume from a snapshot by using the fast restore feature, you can use a different encryption key for the snapshot and for the new volume. If you delete the snapshot encryption key from the key management service, the volume might still become inaccessible when it is attached or reattached to a virtual server instance.

Workaround: To recover the snapshot encryption key, use the key recovery procedure. When the key is recovered, the volume becomes accessible.

Volumes and snapshots omit the catalog offering information for unbilled catalog offering versions

Issue: When you retrieve a volume or snapshot that was originally provisioned as a boot volume in an instance with a billed catalog offering and without a billing plan, the response does not include the catalog_offering property.

File share replication snapshots

When replication occurs between the source share and its replica, the system creates temporary snapshots in the .snapshot directory to support the data synchronization. These system-managed snapshots are named by using the word "replication" and the associated creation timestamp rather than a fingerprint. These snapshots are automatically released and deleted when they are no longer needed. These snapshots are not visible in the console, in the CLI or API responses.

File share snapshots are not visible in UI, CLI, or API responses for Accessor shares

Users of Accessor shares have access to all the data of the source share, which includes the snapshots of the file share. Although users of an Accessor share can't see the file share snapshots of the source share in the console, in the CLI or API responses, they can access the snapshots in the .snapshot directory of the Accessor share.

File share snapshot directory visible property in API response

The property snapshot_directory_visible is included in the API response for the methods that are listing, creating, deleting, retrieving, or updating a file share. This field is not recommended for use, and it is planned to be removed.

Creating accessor share with specific resource group fails

When you specify a resource group explicitly in your API request to create an accessor share for an origin share, the request fails with 400 Bad Request error. As a workaround you can create the accessor share without specifying a resource group, the system automatically picks the default resource group to create the share.

When a cross-regional replica is created, the displayed href value of the parent snapshot is incorrect

When you retrieve information about your cross-regional replica share, the source snapshot's href value is incorrect in the API response. Refer to the source snapshot ID or source snapshot CRN instead.

File share accessor_bindings missing in share API response

When creating, retrieving, listing, updating, or deleting file shares, accessor_bindings may be absent from the share API response.

File share more_info does not return URL of issue

When an error is reported while making share API requests, the more_info property does not return an error topic URL for the issue encountered. The more_info property currently returns information on how to resolve the issue encountered instead.

File share properties missing in API response

Select availability

When using an API version query parameter of 2025-09-15 or earlier, the following properties might be missing or incorrect from the response:

• zone might be absent in the share API response when file shares and file share snapshots with rfs profile from a source share are created, retrieved, listed, updated, or deleted by using an API version of 2025-09-15 or earlier. When a version query parameter of 2025-09-15 or earlier is used, the zone of an rfs share snapshot returns the first zone from the region and is informational only. zone is not affected for dp2 share snapshots and is represented correctly for rfs share snapshots when an API version of 2025-09-16 or later is used.

Creating replica file shares with allowed_transit_encryption_modes or mount targets with transit_encryption

Select availability

When you try to create a replica file share with the allowed_transit_encryption_modes option specified, the request fails. Additionally, creating a replica file share with a mount target without a transit_encryption value in the source share's allowed_transit_encryption_modes property fails. This behavior is incorrect. To work around this issue, do not specify allowed_transit_encryption_modes in requests to create a replica file share. The replica's allowed_transit_encryption_modes are inherited from the source share. When you want to create a mount target for a replica file share, use only the transit_encryption values that are specified in the source share's allowed_transit_encryption_modes property.

Regional file share mount target provisioning delays

Select availability

Creating a share mount target for a regional file share can take more than 10 minutes, during which time its lifecycle_state shows as pending. Mount targets for shares that use the dp2 profile are not affected.

Regional file share snapshot size not reported accurately in API and CLI responses

When performing file share operations with the CLI or API, the snapshot size field defaults to 1 in the response when a snapshot is created and to 0 otherwise. This value does not represent the actual size of the snapshot for regional shares.

Backup plan ID property in the API response

When details of a snapshot are retrieved, the API response shows the property name backup_plan_id instead of backup_policy_plan. A fix for this issue is planned.

Multi-volume backup creation requests create consistency group snapshots without second-generation volumes

Multi-volume snapshots are not supported for second-generation volumes. When you try to create a consistency group of snapshots of a mix of first and second-generation volumes, the API request appears successful as snapshots of Gen 1 volumes are created. However, the Gen 2, sdp volumes are skipped.

The Bandwidth property of first-generation volumes profiles incorrectly displays dependent_range

When details of first-generation volume profiles are retrieved, the responses show the bandwidth type incorrectly as dependent_range. The correct value is dependent because the bandwidth value is automatically assigned by the system, and that value can't be changed manually or programmatically.

Private context-based restriction rules for Backups are not working in Montreal (ca-mon) and Chennai (in-che) MZRs.

Enabling private CBR rules for backup operations that create and manage automated snapshots of block volumes and file shares in Montreal and Chennai is currently not supported.

Block volume snapshot is greater in the remote region than the original snapshot

The first time that you create a cross-regional copy, that snapshot is a full copy of the parent volume's data. Subsequent copies can be incremental or full copies. Whether the remote copy is incremental depends on the immediately preceding snapshot in the chain. If the immediately preceding snapshot exists in the destination region, the copy can be incremental. If the immediately preceding snapshot is not found or it's not stable in the remote region, a new full-copy is created. When a full remote copy is generated from an incremental snapshot, it creates a discrepancy in the billing.

Snapshot encryption in regional Object Storage in Chennai region

Currently, a local Key Protect instance is not available in Chennai. First-generation block volume snapshots that are taken in Chennai are routed to a regional Object Storage bucket that is encrypted by using a Key Protect instance from the London (eu-gb) region temporarily. When the KMS service becomes available in Chennai, the snapshots service will switch to use the Chennai-based Key Protect instance for encryption, so both storage and key management are handled within the same region.

Cross-regional replication for zonal file shares in Chennai

Currently, cross-regional replication for zonal file shares is not supported in the Chennai region.

Cross-regional copy of block storage snapshots in Chennai

Currently, cross-regional copy of block storage volume snapshots is not supported in the Chennai region. It can't be selected as a source or target region.