In func doPeer2PeerMigrate3(), in the "finish" step, it checks whether
domainMigrateFinish3() returns NULL or not.
if it(ddomain) is NULL, it just restarts the guest on the source.
Please consider the scenario that the ddomain has already been running on the dest, but it
fails to tell the source
this fact, and ddomain becomes NULL. If we then restart the guest on the source, there
will be 2 same guests running
on both sides, and a SPLIT-BRAIN occurs.
It seems much better to stop them both , rather than leaving them both running. At least,
when we found the ddomain
is NULL, we should probably check whether the problem is caused by keepAlive failure, if
so, kill the guest on the source
rather than restarting it.
How do you think about that?
BTW, it says that: "The lock manager plugins should take care of safety in this
scenario" in the comment,
with the commit 2593f9692df0f128b14cde811e18aa49c1cf3e06, I don't quite understand
that:
1) If we migrate the guest with the flag VIR_MIGRATE_NON_SHARED_DISK, then nbd server may
take care of the data
consistency, But before it starts the cpus on the dest, the nbd server is already stopped.
So, at this moment, no
one takes care of this problem.
2) If we migrate the guest with a shared disk, then does it mean that the nfs or other
shareing-disk schemas should
prevent split-brain by themselves?