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

**URL:** <https://forum.opennebula.io/t/custom-driver-hook-for-vmm-save-restore-of-the-checkpoint-file/626>\
**Category:** Integration Support\
**Created:** [April 21, 2015, 7:53pm UTC](https://forum.opennebula.io/t/custom-driver-hook-for-vmm-save-restore-of-the-checkpoint-file/626 "2015-04-21T19:53:37Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![atodorov\_storpool](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/atodorov_storpool/32/5327_2.png) [@atodorov\_storpool](https://forum.opennebula.io/u/atodorov_storpool)\
**Post date:** [April 21, 2015, 7:53pm UTC](https://forum.opennebula.io/t/custom-driver-hook-for-vmm-save-restore-of-the-checkpoint-file/626/1 "2015-04-21T19:53:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jfontan](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/jfontan/32/18_2.png) [@jfontan](https://forum.opennebula.io/u/jfontan)\
**Post date:** [April 22, 2015, 9:53am UTC](https://forum.opennebula.io/t/custom-driver-hook-for-vmm-save-restore-of-the-checkpoint-file/626/2 "2015-04-22T09:53:31Z")

</div>

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:

> <https://github.com/OpenNebula/one/blob/master/src/vmm_mad/exec/one_vmm_exec.rb#L415-L436>

Migrate:

> <https://github.com/OpenNebula/one/blob/master/src/vmm_mad/exec/one_vmm_exec.rb#L474-L530>

---

<div class="post-metadata">

**Author:** ![atodorov\_storpool](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/atodorov_storpool/32/5327_2.png) [@atodorov\_storpool](https://forum.opennebula.io/u/atodorov_storpool)\
**Post date:** [April 22, 2015, 11:47am UTC](https://forum.opennebula.io/t/custom-driver-hook-for-vmm-save-restore-of-the-checkpoint-file/626/3 "2015-04-22T11:47:34Z")

</div>

> 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