Recently, I have noticed several relevant open-source workload orchestrators have introduced interfaces for working with Changed Block Tracking (CBT) data, including OpenStack Cinder CBT contract, Kubernetes CSI-snapshot-metadata, OpenNebula OneBex, and the XCP-n XenServer CBT guide.
Proxmox VE, Apache CloudStack, and oVirt do not currently have a storage-side API to query CBT. (Proxmox VE and oVirt do CBT via qcow2 only, but that is outside the scope of this text).
What is CBT?
CBT makes taking backups more efficient. When backing up virtual machine images or container images, the backup system starts with a full backup. Then, at each interval, it retrieves only the data that has changed since the previous VM image.
We already have CBT in DRBD. We call it the change-tracking bitmap. So far, it has been available only for DRBD’s own purpose: tracking data modifications when a peer (replica) is unreachable to the primary node in the quorate partition. We will make DRBD’s CBT available for other users as well. With the next DRBD and drbd-utils release, we will deliver four new commands: start/reset CBT tracking, dump CBT information, read the status, and stop/forget CBT tracking.
In addition, LINSTOR will get CBT support. It will pull CBT data from DRBD, combine it (if necessary), and expose interfaces so connectors can control CBT and retrieve the data.
Why is this relevant for you?
Without CBT, the backup process either has to do full backups every time or compare a complete image with its previous version, which creates a lot of (unnecessary) read load on the storage side.
CBT improves backup efficiency by reducing storage load, network load, and CPU consumption. We’re adding it to the stack now, as the workload orchestrators now provide the necessary interfaces.
Why does this happen now?
I think this is again a consequence of the big VMware exodus. Around VMware is an ecosystem of backup software vendors. As users move to Linux-based hypervisors, backup software vendors need to move as well, which has contributed to the CBT interfaces to the named open-source workload orchestrators.
And shared storage…
Another side effect of the big VMware exodus, paired with higher hardware prices due to the AI hype, is the uptick in users wanting to keep using their existing shared storage (storage arrays, SAN storage targets) with the new Linux-based hypervisors.
On the LINSTOR side, since version 1.35, we revamped shared storage support and now offer it for workloads on Kubernetes and Apache CloudStack. LINSTOR needs to leverage the LVM “thick” code for that. With that in mind, it can only keep a limited number of snapshots. Additionally, snapshots on the primary storage system are not compatible with live migration. The above-mentioned CBT mitigates this limitation.
With CBT, snapshots are kept only as long as the backup software needs to copy the image out.
DRBD will include the CBT feature with the 9.3.5 release, planned for November (and drbd-utils 9.36). LINSTOR will bring CBT support with 1.36. From there, we will add support to our integration plugins with the orchestrators as quickly as possible.
Moving to the latest LINBIT content, we have ‘Methods for Migrating Virtual Machines From VMware ESXi to Linux-Based Hypervisors,’ which adds to the VMware discussion. As system administrators have been migrating away from VMware ESXi because of the extreme increases in total cost of ownership (TCO) since Broadcom acquired VMware, they need to choose the best platform for their environment. This blog post addresses how to get your virtual machines (VMs) and their data onto the new platform.
