Anything I can do to avoid sending snapshots during move?
I know that I am able to copy and swap nodes. What will happen then with snapshot on SOURCE node?
Shall I try to remove all snapshots before move (not ideal situation, but…)?
If you copy, then you should be able to rename the source to a different name and then rename the copy back to the original name.
Yes, I know. That is last resort.
Anything I can do to avoid sending snapshots during move?
No, a move operation requires moving snapshots. You cannot move the parent instance and leave the snapshots orphaned with no parent.
If I delete snapshots before move? Will that help?
It might do yes
Just to report:
after deleting all snapshots, move has finished w/o problems.
So, (in case that previous problems did not happen) will move work with existing snapshots (should do, because zfs send can do it)?
Yes you should be able to move an instance with snapshots irrespective of which storage pool type you are using, or even moving between pool types.
Well, will same move problem appear again (because database constraint problem) once I want to move this INSTANCE again?
So, how to solve this database inconsistency?
I don’t know, can you try it please, I was not able to reproduce any consistency issue when I tried it this morning, suggesting something had been left behind when you had the initial failure (that is what I was hoping to reveal with all the queries I asked you to run).
I was able to move a container on ZFS between two cluster members, back and forth, many times without issue.
So, there was problem with creating config key. Since I have destroyed snapshots, and moved INSTANCE to another node, what will happen with orphan entries in database?
There is NO anymore (definitely) snapshot called auto-20220528-230451, but it is present in DB…?
Hopefully any left overs have been removed now that the instance has been deleted due to referential integrity in sqlite.