Why are CBT-enabled VDIs from VM snapshots checked during pool migration?

[gthvn1]

I created a snapshot of a VDI (with CBT enabled) using VDI.snapshot. Then I tried to migrate the VDI, but since CBT was enabled, it failed (that's fine). I disabled CBT for the current VDI (the snapshot still had CBT enabled) and was then able to perform the migration without issues. It looks ok for me.

However, if I do the same operation using VM.snapshot instead, the migration fails because the snapshot has CBT enabled. Looking into the code, the difference compared with VDI.snapshot is that during pool migration, the system checks for the presence of snapshots. In the case of VM.snapshot, snapshots exist, and all VDIs are checked—including snapshots. If a snapshot was created while CBT was enabled, that snapshot permanently retains CBT, even if CBT is later disabled on the active VDI.

My question is: it seems I can perform VDI live migration even if the VDI has snapshots with CBT enabled (it is the case with VDI.snapshot). Why, then, when the VM has snapshots, do we check the VDIs of the snapshots as well? Could we not just skip the CBT check for snapshots?

[gthvn1]

To give a concrete example I can:

1. enable the CBT on a given VDI: xe vdi-enable-cbt uuid=e90f2da6-3220-40cc-bcf0-f3da0659c2de
2. do a snapshot: xe vdi-snapshot uuid=e90f2da6-3220-40cc-bcf0-f3da0659c2de
3. So at this point I have a VDI snap with CBT (and we cannot disable CBT for this snap)
4. disable CBT on the current used VDI: xe vdi-disable-cbt uuid=e90f2da6-3220-40cc-bcf0-f3da0659c2de
5. And I can successfully do the live migration of the VDI to another SR (on the same host in my case but another SR): xe vdi-pool-migrate uuid=e90f2da6-3220-40cc-bcf0-f3da0659c2de sr-uuid=d835d019-1b97-0080-1bc0-eb52542db3f5

But if instead of doing a vdi-snapshot I do a VM snapshot at step 2, than I cannot do the same VDI migration because it now checks the snapshoted VM that has a VDI with CBT enabled. For me the VDI migration looks the same and if it works in one case I don't see why it cannot be done in the other...

[gthvn1]

After discussing with @last-genius, I realized I had missed an important point: during a VDI pool migration, if the VDI belongs to a VM that has a snapshot, the snapshot VDIs are also moved to the new SR. This does not happen when you create a snapshot directly with VDI.snapshot. If I understand correctly, the issue is that once you have a "base VDI" plus a "snapshot VDI with CBT", you cannot create an independent VDI. However, starting from a "base VDI" plus a "snapshot VDI without CBT", you can.

So it looks like once you have a "base VDI" plus a "snapshot VDI with CBT" the only way to do the VDI pool migration is to delete the snapshot. Is my understanding correct?

[gthvn1]

My idea to be able to migrate VDI with snapshot + CBT is to recursively disable CBT so if the current VDI has CBT disabled all its snapshots will also have CBT disabled. In the code it looks like we cannot disable CBT if it is a snapshot: https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/xapi_vdi.ml#L438
But I didn't understand why we couldn't do it?

[psafont]

There's not much information in the original commit: 68be9f8

[gthvn1]

And in fact I saw it is also prevented by SMAPI: libs/sm/VDI.py

    def configure_blocktracking(self, sr_uuid, vdi_uuid, enable):
        """Function for configuring blocktracking"""
        from sm import blktap2
        vdi_ref = self.sr.srcmd.params['vdi_ref']

        # Check if raw VDI or snapshot
        if self.vdi_type == vhdutil.VDI_TYPE_RAW or \
            self.session.xenapi.VDI.get_is_a_snapshot(vdi_ref):
            raise xs_errors.XenError('VDIType',
                                     opterr='Raw VDI or snapshot not permitted')
...

So xapi maybe just followed the behavior of SM plugin.

[gthvn1]

I did some testing and disabled the check on both the XAPI and SMAPI sides to allow disabling CBT on a snapshot, and nothing seems to have broken. The snapshot now has no CBT log and CBT is disabled. To me, this suggests that we could probably implement recursive disabling of CBT when it is disabled on the current VDI, so that both the current VDI and its snapshots have CBT disabled. This would allow live migration even if a VDI has been snapshotted with CBT enabled. Simply letting the user disable CBT on a snapshot seems to result in an inconsistent state of the CBT chain...

Do you see any issue with recursively disabling CBT when a VDI has a snapshot?

[psafont]

Do you see any issue with recursively disabling CBT when a VDI has a snapshot?

Can there be several VDIs created from a single snapshot? If that's the case, can the snapshot lose CBT while the other VDIs keep it? Or does it impede some operations for the VDIs like reverting to the snapshot?

[gthvn1]

It looks like (I need to do more tests) that when you create a new VM from a snapshot its VDI are created in their own VHD tree. There is no relation between the created VDI and the snapshot if I'm not mistaken. So I think that the VHD tree is always "linear" (it is not the correct term but I think you see what I mean ;) ) ... and it is the same for copy I think.

[gthvn1]

So I opened this issue because live migration is not possible when CBT is enabled on a VDI (either on the current VDI or any of its snapshots). Currently, disabling CBT is only possible on the current VDI. Both XAPI and SMAPI prevent disabling CBT on snapshots. However, we did not observe any issue when disabling CBT on snapshots as well. Since this would allow live migration, we propose that calling VDI.disable_cbt should also disable CBT on all snapshots of the VDI.

Do you see any good reason to not do that?