Hook(s) for Image Datastores on a Live Migration?

Development
1

Is there a built-in or preferred way for an Image datastore to respond to the a live migration of a VM via its postmigrate and premigrate actions?

It seems that only system datatstores have these actions called during a live migration.

2

Hello, I just realize the same!

I’m trying to implement live migration for iscsi driver, but none of these tm scripts are called.

3

Hi,

In our addon I’ve patched the tm/shared/{pre,post}migrate and tm/ssh/{pre,post}migrate scripts to achive live migration.

I’ve described the process in the README.md. search for “Fix ssh TM_MAD driver”

in brief, I am replacing the empty scripts with

#!/bin/bash
[ -d “${0}.d” ] && for hook in “${0}.d”/* ; do source “$hook”; done

Then create placeholder

mkdir -p /var/lib/one/remotes/tm/ssh/{pre,post}migrate.d

And create relative symlinks to your {pre,post}migrate scripts.

This way every addon can drop or its script in the corresponding *.d folder. The only need is for the script to check and do action only on the disks related to its driver.

Kind Regards,
Anton Todorov

4

Thanks Anton,

I was thinking about replacing shared system tm scripts with one looping over disk types in VM and calling appropriate premigrate/postmigrate scripts from their TM directory.

5

Hi Michal,

IMO the disk type is not enough to know what driver to call. Just check what could be configured in single VM libvirt: Domain XML format

IMO There are no strict mapping between the tm_mad driver names and the disk types. So I’ve decided that it should be better each concerned driver/developer/ to drop a snippet that can detect the disk and do needed actions to attach/detach the block device/file/whatever.

(Similar issue you will hit when you reach the VM disks usage polling - currently(without patching) it works only for RBD and qcow2 files… Just ask if anything in my patches is not clear there. Hopefully in v5 the issue will be resolved.)

Kind Regards,
Anton Todorov

Kind Regards,
Anton Todorov