Source and classification

• Source: Internal Jira/TIC.
• Classification: Product issue.
• Confirmation basis: The TIC reproduced the issue consistently in a SAN environment. The current top layer could not be mounted, while both image caches could be mounted. The analysis found that SharedBlock resize performed a shrink with an incorrect size, leaving the volume at only about 64 MB. The code for ZSV-8228 adds a check before resize to skip the operation when the current virtual size is already sufficient.
• Internal tracking: TIC-3700 and ZSV-8228.

Issue metadata

• Issue IDs: TIC-3700 and ZSV-8228
• Component/product: ZVF ZSphere
• Status: Fixed
• Reported/affected version: 4.10.3
• Last updated: September 2, 2026

Problem description

On the SharedBlock/SAN path in 4.10.3, exporting an OVA or creating an image after shutting down a virtual machine enters a qcow2 resize/commit-related process. The old code did not first compare the current virtual size and still allowed qemu-img resize --shrink when the upper layer supplied an incorrect smaller size. Existing analysis observed that the original volume was truncated to about 64 MB, after which the superblock and data of the Linux root file system became unreadable. The fix enables skip_if_sufficient for SharedBlock offline resize: when the current qcow2 virtual size is greater than or equal to the requested value, the shrink is skipped.

Symptoms

• Windows virtual machines might start normally, while Linux virtual machines such as CentOS 7.9 cannot start.
• Startup logs show XFS file system errors and bad superblock, and xfs_repair cannot repair the file system. Checking the virtual volume size shows that it has been abnormally reduced.
• /dev/centos/root on the current top layer cannot be mounted through libguestfs, while the root file systems of the associated image caches can still be mounted. A healthy image cache proves only that the base image is intact; it cannot restore subsequent business data from the virtual machine.
• The issue can be reproduced consistently on SAN/SharedBlock data storage and has not been reproduced on local storage.

Impact

The original virtual machine volume is truncated and might be unrecoverable. This is a data safety issue, not merely an export task failure. Expanding the truncated LV back to its original size does not restore lost data, and repeatedly running xfs_repair might further alter the only available evidence.

Workaround

• Verified self-service workaround: Before upgrading a 4.10.3 SAN/SharedBlock environment, stop using Create image from existing virtual machine/disk and Export OVA. Do not use a production virtual machine to test whether the issue is present. The fact that Windows can start or that the issue is not reproduced on local storage does not prove that SAN-based Linux virtual machines are safe.
• After the issue occurs, immediately stop virtual machine startup, OVA export, resize, commit, and file system repair operations. Preserve the task UUID, volume/snapshot chain, virtual sizes before and after export, Agent logs, and lock status. First create storage-side read-only protection or a copy of the affected LV.
• There is no verified general temporary method for repairing data that has already been truncated. With support assistance, recovery can only use a verified backup from before the export, a storage snapshot, or another complete copy to restore data to a new volume. The image cache can rebuild only the base system and cannot replace a business data backup.
• Recovery success criteria: The new volume size matches the backup, the read-only file system check passes, and the virtual machine starts on an isolated network and passes business validation. If the backup is also damaged, the size is inconsistent, or mounting fails, preserve the environment and do not continue attempts on the original volume.
• After a preventive upgrade, first use a disposable test virtual machine on SAN to perform one shutdown, OVA export, restart, and data validation cycle. Confirm that the virtual size of the original volume remains unchanged before resuming production exports.

Affected products

• ZVF ZSphere: 4.10.3
• Deployment and dependent components: OVA export involving an XFS data disk on SAN data storage. Do not apply this issue conclusion when the environment does not use XFS, does not use SAN, or has not performed an OVA export.

Fix status

• Current status: Fixed.
• Fixed version: 4.10.6. Local commit history shows that ZSV-8228 was merged into zsv_4.10.6.
• Related defect/fix record: ZSV-8228. shared_block_plugin.resize_volume() calls qemu_img_resize(..., skip_if_sufficient=True), so a shrink is no longer performed when the current virtual size has already reached the requested value.

Related information

• Related TIC/Jira: TIC-3700 and ZSV-8228.