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

atodorov_storpool · April 21, 2015, 7:53pm

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:

do changes in the files and keep them in our addon
pros: looks easy to create a patch
cons: not compatible with upgrade
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
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

jfontan · April 22, 2015, 9:53am

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:

github.com

OpenNebula/one/blob/master/src/vmm_mad/exec/one_vmm_exec.rb#L415-L436


end


#
# SHUTDOWN action, graceful shutdown and network clean up
#
def shutdown(id, drv_message)


    action = VmmAction.new(self, id, :shutdown, drv_message)


    steps=[
        # Shutdown the Virtual Machine
        {
            :driver     => :vmm,
            :action     => :shutdown,
            :parameters => [:deploy_id, :host]
        },
        # Execute networking clean up operations
        {
            :driver   => :vnm,
            :action   => :clean

This file has been truncated. show original

Migrate:

github.com

OpenNebula/one/blob/master/src/vmm_mad/exec/one_vmm_exec.rb#L474-L530


            :action     => :save,
            :parameters => [:deploy_id, :checkpoint_file, :host]
        },
        # Execute networking clean up operations
        {
            :driver   => :vnm,
            :action   => :clean
        }
    ]


    action.run(steps)
end


#
# RESTORE action, restore a VM from a previous state, and restores network
#
def restore(id, drv_message)
    xml_data = decode(drv_message)


    tm_command = xml_data.elements['TM_COMMAND']

This file has been truncated. show original

atodorov_storpool · April 22, 2015, 11:47am

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

Topic		Replies	Views
Hook(s) for Image Datastores on a Live Migration? Development	4	1128	May 14, 2016
Snapshot entire vm backed by custom storage driver Community Support	2	437	September 7, 2018
Shared mode for the ceph based system datastires Development	13	1673	April 29, 2019
VMs deleted after onevm stop Development	2	1108	November 22, 2016
Question about VM migration Community Support	5	51	February 25, 2025

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

Related topics