calvix opened a new pull request, #14656: URL: https://github.com/apache/cloudstack/pull/14656
### Description Encrypted RBD roots created by #13556 can develop filesystem corruption on their first boot when the parent template contains sparse ranges. Reproduced with an Ubuntu 26.04 template on KVM + Ceph. The guest reported: ``` EXT4-fs error (device vda13): ext4_validate_block_bitmap: comm ext4lazyinit: bg 6: bad block bitmap checksum ``` `e2fsck -fn` confirmed corruption on /boot. Some instances also suffered root filesystem errors and remounted it read-only. The problem occurs when a guest write triggers copy-up of a parent object containing holes. Those ranges can return garbage through the clone’s encryption layer instead of the original zeros. In this case, a hole contained an `ext4` block bitmap, and writing the superblock in the same object triggered the corruption. ### Fix Before creating the encrypted-clone snapshot, rewrite the template from `cloudstack-base-snap` using `qemu-img convert -n -S 0` to write out its sparse ranges. Create the base snapshot first if the template has never been used for a plaintext clone. The rewrite receives the caller's timeout. Use a new snapshot name, `cloudstack-base-snap-luks2`, so templates prepared by the old code are prepared again. Encrypted roots remain thin clones; plaintext roots continue using `cloudstack-base-snap`. This fully allocates the template once per pool. It prevents corruption in new roots but does not repair existing ones. ### How Has This Been Tested? `RbdEncryptionTest`, `LibvirtStorageAdaptorTest` and `KVMStorageProcessorTest` pass: 90 tests, no failures or skips. Checkstyle reports no violations. The regression tests cover encrypted-first deployment, upgrading the old `-luks` snapshot, reusing an already-prepared snapshot, failed conversion and retry, duplicate-snapshot handling, snapshot creation failure, dense-copy options and timeout propagation. Duplicate-snapshot handling is tested with mocks; it does not prove simultaneous preparation works. `QemuImgTest` includes a real dense-allocation test, which requires qemu-img and libvirt and was not run in this validation environment. Live testing used the original dense-copy change backported to 4.23 on a three-node KVM + RBD cluster: - An Ubuntu 24.04 template with an existing `-luks` snapshot produced a fully allocated `-luks2` snapshot. Encrypted and plaintext VMs both booted. - In ten objects containing sparse ranges, a write elsewhere in the object caused the old clone to return nonzero data from all ten previously zero ranges. The new clone preserved zeros in all ten. - An Ubuntu 26.04 encrypted VM booted without ext4 errors. After approximately 3.6 GiB of writes, `/boot` and EFI filesystem checks were clean, and the root remained read-write. - Repeating the preparation without filling holes reproduced the `/boot` bitmap corruption on first boot. Concurrent preparation and templates larger than 4 GiB have not been tested live. The subsequent preparation and timeout changes have unit coverage but have not been retested on the live cluster. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
