abh1sar commented on code in PR #14386:
URL: https://github.com/apache/cloudstack/pull/14386#discussion_r4347573474
##########
plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreBackupCommandWrapper.java:
##########
@@ -381,6 +457,212 @@ private boolean
replaceBlockDeviceWithBackup(KVMStoragePoolManager storagePoolMg
return true;
}
+ /**
+ * Rebuild an RBD image by replaying a chain of {@code rbd export-diff}
streams into it: the
+ * chain's full anchor first, then each incremental in the order it was
taken.
+ *
+ * <p>RBD images are raw and cannot hold a backing-file reference, so —
unlike the qcow2 path —
+ * a diff carries no pointer to the one before it and the chain cannot be
flattened by
+ * {@code qemu-img}. Ceph applies the deltas natively instead: each diff
ends at the snapshot
+ * the backup was taken from, {@code import-diff} recreates that snapshot
on the target, and the
+ * next diff in the chain is validated against it. A truncated or
out-of-order diff is therefore
+ * rejected by Ceph rather than silently producing a half-restored
image.</p>
+ *
+ * <p>The image is recreated first. A full diff only carries the extents
that were allocated
+ * when it was taken, so any block still allocated in the current image
would otherwise show
+ * through the restore as stale data. Recreating the image also drops
every RBD snapshot it
+ * carried: a restore rewinds the volume wholesale, and snapshots of
content that is being
+ * replaced cannot be kept. The chain anchors this path takes are ours to
drop, but a snapshot
+ * taken outside it — a CloudStack volume snapshot kept on primary
storage, say — is not, so an
+ * image carrying one is refused rather than rewound.</p>
+ */
+ private boolean restoreRbdImageFromDiffChain(KVMStoragePoolManager
storagePoolMgr, PrimaryDataStoreTO volumePool,
+ String volumePath,
List<String> diffFiles, Long size) {
+ if (!Storage.StoragePoolType.RBD.equals(volumePool.getPoolType())) {
+ logger.error("Backup [{}] holds RBD diffs but volume [{}] is on {}
storage; it cannot be restored there.",
Review Comment:
This is a behavior change from other primary storage backups and full
ceph-rbd backups. In other cases a Backup taken from any primary storage can be
restored on any other primary storage.
Can we do something about it? or we should atleast make this clear in the
documentation.
--
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]
