Update failmigrate

[atodorov-storpool]

It is obvious that I've totally missed the tm/failmigrate script when proposed the migrate_other function

Here are three commits:

• tm/fs_lvm - besides the call of migrate_other() I think it is good idea to deactivate the LVM volumes enabled by the tm/fs_lvm/premigrate on DST_HOST
• tm/ceph/failmigrate - same as for the above commit - I believe it is good to clean up the DST_HOST if the live-migration fails
• tm/{qcow2,shared,ssh} - do migrate_other() when failmigrate

Kind Regards,
Anton Todorov

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. The OpenNebula Dev Team

[atodorov-storpool]

Well IMO the issue is not completely resolved. IMO each core TM_MAD should have algo to call cleanup for other TM_MADs. Otherwise artefacts will be left on the (failed) destination.

[rsmontero]

@atodorov-storpool Trying to understand the migrate_other, it is used to have a list of TM's in the DISK TM_MAD to support disks from different datastore types, but this is not supported. So I'm wondering if this and the migrate other can be remove, or if storpool driver is using this?

[atodorov-storpool]

Hi @rsmontero

@atodorov-storpool Trying to understand the migrate_other, it is used to have a list of TM's in the DISK TM_MAD to support disks from different datastore types, but this is not supported. So I'm wondering if this and the migrate other can be remove, or if storpool driver is using this?

Can't get the unsupported part because this is how most[*] of the addon storage drivers are working with OpenNebula :-)
If I manage to drive you through an example case will help to understand the point. Let's have an OpenNebula installation with SYSTEM datastore TM_MAD qcow2 and an additional IMAGE datastore with TM_MAD storpool. And a VM could have a disk from the StorPool-backed datastore... When Instantiated on a host, the tm/storpool/ln (or clone if the image is non-persistent) is called to provide the symlink in the VM's home folder (on the qcow2-backed SYSTEM datastore) to the block device. So, on VM migrate the tm/qcow2/premigrate script is called. This script natively does not know how to deal with the storpool disk - here the migrate_other function helps by walking the VM disks and calling the tm/DISK[TM_MAD]/premigrate script that provides the storpool disk on the destination host. Same for postmigrate and failmigrate.

[*] AFAIK addon-linstor-un maintained by @kvaps and addon-3par maintained by @feldsam are benefiting from this functionality too.

p.s. There was a discussion and a fix for the SSH-backed System datastores to exclude the block devices from the blockcopy, but I can't find it at the moment.