Volume shows incorrect size or 0 in UI after resize of VCF Management component volume

Products

• VCF Operations

Issue/Introduction

In the VCF Operations UI (Build > Lifecycle > VCF Management > Components > [Component] > Actions > Increase Storage Size), the Storage Size of a components volume has been increased.

• The volume capacity displays as 0 in the UI for the specific volume storage size increased, and subsequent resize attempts fail with "Unsupported unit".
  
  OR
  
  
• The volume capacity displays correctly, but subsequent resize attempts appear successful but the size remains unchanged.

Note: No data loss occurs in either state. The 0 display is a metadata formatting issue only.

Environment

VCF Operations 9.1

This issue may be present for the following components within VCF Operations:

• Identity Broker
• VCF Automation
• Fleet Lifecycle
• SDDC Lifecycle
• Real-time metrics
• Salt Master
• Salt RaaS
• Log Management
• Software Depot

Cause

An internal conversion bug incorrectly rounds byte values when crossing IEC unit boundaries (e.g., GiB → TiB at 1024 GiB, MiB → GiB at 1024 MiB). Values that don't divide evenly produce decimal IEC values (e.g., 1.47Ti) that the backend stores as millibytes (ex - 80541374218240m) - a format the UI cannot render (shows 0) and the pre-check cannot process for further expansions.

Resolution

Safe Expansion Rules:

To avoid this issue always use target volume sizes that land exactly on a 1024 boundary or stay within the current unit range:

If the current size is:	Then the safe target sizes are:	And unsafe target sizes are:
< 1024 GiB	Any whole GiB value < 1024	≥ 1024 GiB
≥ 1024 GiB	Exact multiples of 1024 only (e.g., 2048, 3072 GiB)	Any value between multiples

 

Note: If a volume is already at 1024 GiB, the minimum safe increment is +1024 GiB (to 2048 GiB). There is no safe smaller increment. If a 1024 GiB increment is not feasible, proceed with your required resize amount and if you hit the issue mentioned in this document, then follow the Workaround steps below to correct the resulting UI display issue using the provided script.

 

Workaround:

If a volume is already showing 0 (meaning the volume cannot be resized further), use the attached script to reset the metadata.
This script safely interacts with the VCF Services Runtime to increase the volume to the next safe boundary, clearing the 0 value without affecting your underlying data.

The attached script runs in three modes -

• Scan - Scans all volumes across all namespaces. If affected volumes are found, it outputs the exact commands with pre-filled parameters needed to fix them.
• Fix with Dry-Run - Validates the generated fix command against the cluster to ensure success without making any actual changes.
• Fix - Executes the generated commands to increment the volume out of the unresolvable millibyte state.
  
  Note: This is a one-time metadata correction, not a permanent patch for the underlying bug. This script is strictly for recovery and cannot be used as a general-purpose tool to expand volumes to arbitrary sizes.
  
  

  IMPORTANT: Do not modify or manually guess the parameters in the fix commands. The scan output generates the exact, strictly calculated commands required for your specific environment. Copy and paste the generated commands exactly as provided. Altering these values may cause the script to target the wrong volume or fail.

1. Login to the VCF Operations UI and browse to Build > Lifecycle > VCF Management > Components
2. Click on the link for VCF Services Runtime
3. Scroll down to the Nodes section and take note of the IP address of a Control Plane node.
4. SSH to the Control Plane node as the user vmware-system-user
5. Run the following commands:

   sudo su
   export KUBECONFIG=/etc/kubernetes/admin.conf

6. Copy the attached script to the /home/vmware-system-user/ directory of the Control Plane node using an SCP utility.
7. On the Control Plane node run the following commands:

   cd /home/vmware-system-user/
   chmod +x /home/vmware-system-user/volume_resize_millibyte.sh 
   ./volume_resize_millibyte.sh scan

8. The scan will output a list of commands to run with parameters for any affected volumes (If there are any affected volumes)
   If the script output mentions "No millibyte issues found in any namespace." then there is no need to proceed.
9. (Optional) As the script provides a --dry-run option, the outputted commands from step 7 can be used with the following syntax:

   ./volume_resize_millibyte.sh fix --dry-run --namespace {ns} --pd {pkg} --statefulset {sts} --volumeGroup {vg} 

   --dry-run details exactly which Kubernetes API calls will be made (e.g., patching the PD override, deleting STS with --cascade=orphan, etc.) before any actual changes are applied.

10. Use the commands provided by step 7 to apply the fix to the affected volumes, the commands will have the following syntax:

    ./volume_resize_millibyte.sh fix --namespace {ns} --pd {pkg} --statefulset {sts} --volumeGroup {vg} 

11. In the VCF Operations UI, browse to Build > Lifecycle > VCF Management > Components

12. In the top-right of the screen there is a link to Sync.

13. Click this link to sync lifecycle metadata, and confirm that the correct volume size is now displayed.