when I use --enable-cbt on a running VM, the VM is stopped and afterwards started again. This is fine. However, if the VM is stopped (because of a previous shutdown, for example) prior to --enable-cbt, the VM will be started nevertheless.
Is it a requirement to start the VM for properly setting up CBT, or could this behavior optimzed so that only previously running VMs are started again after --enable-cbt?
The same also applies to --reset-cbt were the VM is also started even if it was turned off before.
--enable-cbt is just a helper, if the default behaviour does not suit your needs, just enable CBT manually.
We will improve the helper function in some future release.
From your comments I understood that it is NOT a requirement to start the ctk enabled or ctk reset VM after a change of the ctk settings. If this understanding is correct, I would recommend to start a VM after ctk actions only if the VM state prior ctk actions was running. Otherwise the VM should remain in off state.
However, if there is a way to circumvent this behavior by running the appropriate ctk actions by myself, this is fine.
With regard to --enable-cbt, I understand that the only action performed by xsibackup are ctk enable actions applied to the respective VM which can clearly also be done independent from xsibackup.
What needs to be done for --reset-cbt? Would be the correct replacement handling to disable ctk and then enable ctk again, and, in addition, to delete the .xsi folder within the VM folder?
Exactly!. --enable-cbt and --reset-cbt just save you from the hassle to have to edit the .vmx manually or add the options via the GUI. Also deleting the .xsi dir is a must to prevent problems. The .xsi dir will be created automatically if it does not exist.
Yes, you are right in that the VM state should be considered when running that argument. CBT feature is just weeks old, it lacks some refinements that will be added in next versions.