Custom driver/hook for vmm save/restore of the checkpoint file

Hello developers,

I am working on extension of the StorPool addon to enable support for the system datastore. I am not sure what is the proper way to handle the checkpoint file. I found that it is created via vmm/save and used by vmm/restore script.
To achieve integration I see few solutions but can not determine which one to take:

  1. do changes in the files and keep them in our addon
    pros: looks easy to create a patch
    cons: not compatible with upgrade

  2. clone all vmm hooks to our addon with separate name something like 'vmm/kvm-storpool’
    pros: upgrade independant
    cons: extra work to keep things in sync with upstream. probability to keep different versions for each release

  3. propose feature with patch to add pre/post includes in the above scripts(probably to other too) as upstream solution.
    pros: upgrade independent - extra files not touched on upgrade
    cons: should walk the entire path to become mainstream solution
    Something like this:

# just after after arguments processing
[ -f “$0.pre” ] && . “$0.pre”

# at the end
[ -f “$0.post”] && . “$0.post”

What is your opinion on the topic?

Best Regards,
Anton

What are those scripts expected to do? Maybe the same scripts as pre/post migrate can do:

  • Pre migrate
    • Create checkpoint volume if it does not exist
    • Attach the volume to the node
    • Create a symlink checkpoint -> attached device
  • Save
    • Write to the symlink -> attached device
  • Post migrate
    • Delete symlink
    • Detach device

Right now those scripts are not called for save/restore but maybe the solution is to change that upstream. I have to check the implications with my colleagues.

Save:

Migrate:

What are those scripts expected to do?

I am thinking for the same solution. I should check do virsh save/restore work with symlink to block device and figure out the max size of the block device to allocate - I expect something like VM RAM + a little bit more to be sufficient.

Your suggestion for pre/post migrate integration sounds reasonable.
In our driver I am interfering with premigrate and postmigrate in other TM drivers - shared and ssh ones(for live migration). On clean installation there are empty scripts and it looks OK to replace them but if another storage addon is enabled (like addon-iscsi-equallogic), the task to merge both of them becomes complicated.

What do you think about solution like - instead of “empty” script there to be script that sources all files from given subdir, like:

if [ -d “$0.d” ]; do
for hook in $0.d/* ; do
. "$hook"
done
fi

the resulting directory tree structure will look like this:

tm/shared/premigrate <-- main script that is calling following the files in the subdir
tm/shared/premigrate.d/equallogic
tm/shared/premigrate.d/storpool

This way I do not need to mess with the original ONE scripts but I can add my hook that query and check that there is work to do in our driver. The implementation in addon-iscsi-equallogic addon is checking the driver, our addon is checking the driver too so both scripts could coexist without collision and independent from ONE upgrades.

Similar example for vmm/save:
If in vmm/save is only arguments parsing and then is used above schema, but the hooks are with ordering prefix like

vmm/kvm/save <-- main script that is accepting ARGS sourcing common functions etc, then:
vmm/kvm/save.d/100-save <-- the actual worker

This way I can easily include pre/post code without interfering with original ONE files with just prefixing my scripts.

I believe there are other scripts that can be extended in similar way too.

My english is not native but I hope that you understand what I mean.

Best Regards,
Anton