> I'm wondering what the possibilities of two-way replication are for a > ZFS storage pool.
Based on all the description you gave, I wouldn't call this two-way replication. Because two-way replication implies changes are happening at both sides, that need to be propagated and merged both ways. What you're talking about is to have a one-way replication, and then later, reverse the direction, and then later reverse the direction. At all points, your changes are only happening at one side. This is infinitely easier than what your subject implies. Unless somebody knows more than I do ... As for VM's, I think it's important that you know you shouldn't expect live sync. If you send a snapshot of a local pool to the remote side, then 1 second later the remote pool is already 1 second behind, and in a possibly different state than the local pool. If you fail the local pool, you'll have to connect to the remote pool, and tell your VM to revert to whatever the latest snapshot was on the remote pool. Thinking about how to migrate back to the local storage ... Suppose you have a local snapshot called "tank at 12345" and you send it to the remote side. That means these two filesystems are now in sync at that snapshot. If you can, make the local filesystem read-only as long as you're making modifications on the remote side. Then you can send an incremental snap from remote "tank at 12345" to "tank at 23456" back to the local side. Make the remote side read-only while you're allowing modifications to the local side, and vice-versa. The complication that could arise, is when you want to send an incremental snap to a filesystem which has been modified after the "baseline" snap was taken. This would happen if you synced the two sides, and made modifications to the local side, and had an unintentionally failed local pool. You would then connect your VM to the remote pool, and made modifications to the remote pool. When your local pool comes back online ... These two pools were synced some time ago, but they've both been modified since. You would have to find a way to revert the local pool back to the snap where they were in sync (I don't know how to do that, I don't know for sure it's even possible). You would have to acknowledge risking the loss of local changes that happened after the sync. And you would send the remote incremental snap @23456 to the local side.
