Unable to Resize Boot Volumes of Virtual Machines Migrated from vCenter using Vjailbreak Tool

Problem

After migrating virtual machines (VMs) from vCenter to Platform9 Cloud Director (PCD) using VJailbreak, the boot volumes of these migrated VMs cannot be resized. Although the resize operation appears successful in both the UI and CLI, the actual disk size remains unchanged.

This issue is specific to migrated VMs — newly created volumes within PCD can be resized without any problem.

Environment

• Block Storage
• Private Cloud Director Virtualization - v2025.4 and Higher
• Private Cloud Director Kubernetes – v2025.4 and Higher
• Self-Hosted Private Cloud Director Virtualization - v2025.4 and Higher
• Self-Hosted Private Cloud Director Kubernetes - v2025.4 and Higher

Answer

The issue occurs exclusively with VMs migrated from vCenter using VJailbreak. When attempting to extend the bootable volume through the PCD UI or CLI, the underlying disk size remains unchanged, even though:

• The resize request is accepted and processed by the UI.
• The updated size appears in the output of openstack volume show <volume-uuid>.
• The actual disk file (qemu-img info) continues to show the old size.

In contrast, volumes created directly within PCD (not migrated from vCenter) resize correctly.

Furthermore, the logs (ostackhost and pf9-cindervolume-base) do not record any resize operation for the affected volumes, indicating that the resize process is not being initiated at the storage layer for migrated volumes.

No errors appear in relevant service logs, and the operation completes without any visible failure but does not apply any changes to the backend volume.

Sample output from Affected volume:

$ openstack volume show <VOLUME-ID>

# (Shows updated size: 35GB)

​

$ qemu-img info /opt/pf9/data/state/mnt/.../volume-<VOLUME-ID>

# (Still shows old size: 31GB)

This issue is a known bug and is being tracked under Jira ID PCD-4061. Please contact Platform9 Support if you encounter a similar problem.

Additional Information

• Verified the issue in test environment and successfully reproduced the same behavior.
• No error entries found in _ostackhost_ or _pf9-cindervolume-base_ logs during resize attempts.