F #2352 #2359 #2981 #3130 #3233: Fix fs_lvm cleanup and offline migration issues

[kvaps]

Note for reviewer:

This PR includes the next fixes:

1. Remove check for /VM/TEMPLATE/DISK[DISK_ID=$DISK_ID]/TYPE solves problem with offline and datastore migration. fixes fs_lvm offline migration does not work #2359 and LVM datastore migration does not work #3130. Add check for LCM_STATE instead, fs_lvm driver now correctly disables logical volume during undeploy VM.

2. Fix directory cleanup during termination undeployed VM for storage with the BRIDGE_LIST variable set. The expression for finding DS_SYS_ID was never work if DST_PATH is directory. fixes Destroy VM isn't working with BRIDGE_LIST and UNDEPLOYED VMs #2981 (comment) and LVM cleanup executes on master instead storage node #2352

3. Fix when node in BRIDGE_LIST have no activated lvm device, so zeroing is not working. Now it will always activate the device before zeroing.

[kvaps]

@xorel please review the changes

[xorel]

Could you please also rebase to get rid of the conflict with the missing DD_BLOCK_SIZE?

[kvaps]

Could you please also rebase to get rid of the conflict with the missing DD_BLOCK_SIZE?

Done, I've also replaced DST_PATH check with internal is_disk function:

one/src/tm_mad/fs_lvm/delete

Lines 47 to 51 in 515ee09

	if [ `is_disk $DST_PATH` -eq 1 ]; then
	DS_SYS_ID=$(echo $DST_PATH | $AWK -F '/' '{print $(NF-2)}')
	else
	DS_SYS_ID=$(echo $DST_PATH | $AWK -F '/' '{print $(NF-1)}')
	fi

[kvaps]

Found the problem, when we executing delete operation on the BRIDGE_LIST node, device if not removing from the device mapper on the current node, where volume was activated, that's prevent attaching the new drives on same place.

Another words we should find BRIDGE_LIST node only in case if VM is stopped or undeployed

[xorel]

That's good point.

OK, I did some tests and realized that detecting the UNDEPLOYED using the LCM check 10|30|41|42 is wrong, when the fs_lvm/delete is called the LCM_STATE is always 11 (EPILOG) no matter the previous state (except some error states), that was introduced by me by mistake.

So, I am afraid the only way how to detect if the BRIDGE_LIST should be used is tho compare
the $DST_HOST and the HOST from the VM history, like you did before.

And third point, it seems that we are completely missing the device mapper clanup, I think we shoul call dmsetup remove after each lvremove.

This thing now bloated quite a lot and I am thinking starting again from scratch and tackle the issues one by one.

[kvaps]

using the LCM check 10|30|41|42 is wrong, when the fs_lvm/delete is called the LCM_STATE is always 11 (EPILOG) no matter the previous state (except some error states), that was introduced by me by mistake.

You're right, this check is working fine for the fs_lvm/mv action, but it is wrong to use it for delete.
Let me fix that.

And third point, it seems that we are completely missing the device mapper clanup, I think we shoul call dmsetup remove after each lvremove.

We don't have to, because it is automatically done by lvremove command.
This is just should be run on the same host where VM is located (if it's deployed)

[kvaps]

@xorel, I've found elegant solution: [ "$LAST_HOST" != "$DST_HOST" ] - means running on frontend.

Commit (a075eb9) force pushed to the branch for replace last wrong changes.

[xorel]

@xorel, I've found elegant solution: [ "$LAST_HOST" != "$DST_HOST" ] - means running on frontend.

OK, this seems to work better.

One more detail, when testing I noticed that after offline migration the LV remains active on the SRC_HOST, I suppose the mv action should always deactivate the LV and only if the action is stop or undeploy
then exit. I don't see any other scenarios when the SRC LV should not be deactivated.

[kvaps]

after offline migration the LV remains active on the SRC_HOST, I suppose the mv action should always deactivate the LV and only if the action is stop or undeploy
then exit.

Indeed

I don't see any other scenarios when the SRC LV should not be deactivated.

When copying from the frontend (deploy)

! [[ "$LCM_STATE" =~ ^(31|50)$ ]]

[kvaps]

Found another problem: undeploy --> deploy on selected datastore is not working
but it seems that it is not our bug, tm driver always calls with the same path during deploy

[kvaps]

after offline migration the LV remains active on the SRC_HOST, I suppose the mv action should always deactivate the LV and only if the action is stop or undeploy
then exit.

Indeed

I don't see any other scenarios when the SRC LV should not be deactivated.

When copying from the frontend (deploy)

solved