Issue/Introduction

This article troubleshoots a full clone of an SBLK thick-provisioned virtual machine in 4.10.7 failing when available image storage capacity is less than the disk specification. There is currently no verified fix that performs a precheck based on actual data usage; reserve space based on the virtual disk capacity before proceeding.

Symptoms

A full clone of an SBLK thick-provisioned disk fails in ZSphere 4.10.7. When available image storage space is less than the disk's specified capacity, the operation might fail even if little data is actually written.

Environment

• Product: ZVF ZSphere
• Version: 4.10.7 (reported environment); check the status of related improvements for other versions
• Components: ZSphere full clone, SBLK thick provisioning, snapshot chain, and the image storage/backup server that provides staging capacity
• Deployment: Full clone uses image storage for staging, and the destination virtual machine requires an independent copy of the data

Possible causes

• The full-clone path is "create a source-disk snapshot > upload the snapshot chain to image storage > send it to destination data storage > create a new virtual machine." The space check occurs at the image-storage staging stage.
• Version 4.10.7 evaluates image storage space for an SBLK thick-provisioned disk by the disk specification rather than reducing the reservation to guest-written data. The operation therefore fails when image storage is smaller than the specification even if actual data usage is low.
• Multiple disks, existing images/backup data, and temporary files from failed tasks further reduce available space, but arbitrary directories must not be treated as deletable cache.
• The related development item only records a possible improvement to obtain actual capacity and remains Open. Do not promise that upgrading to a particular version removes the specified-capacity requirement.

Resolution

1. Calculate the specified capacity of every thick-provisioned disk

• Check: Source VM root/data disk UUIDs, thick-provisioning state and specified capacity of each disk, and full-clone mode.
• Location: Collect the values from platform VM/disk details; do not substitute guest file-system usage for specified capacity.
• Expected result: A per-disk specification list for this upload path. Available image storage space must cover at least the specifications of the thick-provisioned disks to upload plus temporary task space.
• Exception handling: Do not apply this capacity rule if a disk is thin-provisioned or the task is not a full clone.

2. Compare actual available image storage capacity

• Check: Selected image storage, capacity available before the task, existing valid objects, and other tasks in the same window.
• Location: Reconcile platform capacity with the underlying file system/storage quota and confirm which image storage the task selected.
• Expected result: Available capacity exceeds the thick-provisioned specification to be staged and leaves headroom for normal platform operation. This article provides no unverified fixed additional percentage.
• Exception handling: If available capacity is less than the specification of any thick-provisioned disk to upload, that explains the failure. Do not repeatedly submit the task and create temporary objects.

3. Confirm that failure occurs while uploading the snapshot chain

• Check: Clone task UUID, temporary source-disk snapshots, image-storage upload logs, destination-storage delivery, and post-failure snapshots.
• Location: Locate the failure by stage: create snapshot > upload > deliver > create virtual machine. After a task completes, check and delete unneeded temporary snapshots through the platform. When a task fails, first confirm whether a snapshot is still referenced by the task or recovery chain; do not delete it directly.
• Expected result: Insufficient space occurs during image-storage selection/upload, before the destination virtual machine is created. Temporary snapshots and objects can be mapped one-to-one to the task.
• Exception handling: If upload succeeded and failure occurred on destination storage or during VM creation, handle the innermost error. Directory-level image-storage cleanup is prohibited.

4. Use fast clone or expand image storage

Workaround

• Verified site method: The customer case temporarily completed the objective with Full fast clone. Before using it, confirm that the current storage/version supports it and that destination-copy independence and later migration/deletion semantics meet business requirements.
• Long-term capacity method: Expand the selected image storage so that its available space meets the thick-provisioned specification. Clean up only objects that the platform confirms are expired and unreferenced.
• Expected result: The clone completes, the destination virtual machine starts and passes data validation, and source and destination VM lifecycles conform to the selected clone method. Clean up temporary snapshots after confirmation.
• Exception handling: If fast clone is unavailable, or the business requires a fully independent copy but capacity cannot be expanded, there is no general workaround. The related development item is not fixed; submit exact disk specifications, image-storage capacity, and the failed stage for product support.

Additional information

• Support information must include the exact time window, resource and task UUIDs, complete error text, and relevant component logs.
• Do not extrapolate one site result to all versions. If the root cause remains open or an operation might affect services or data, stop self-service handling and submit the evidence listed in this article.