You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously `MIRROR.receive_start2` is called as a remote function, i.e.
`Remote.DATA.MIRROR.receive_start2` and it will be forwarded to the
destination host and multiplexes based on the destination SR type.
This is inconvenient as what `receive_start2` should do is more
dependent on what the source SR type is. For example, if the source SR
is using SMAPIv1, then `receive_start2` needs to tell the destination
host to create snapshots VDIs, while this is not necessary if the source
SR type is of SMAPIv3. Hence instead of calling `Remote.receive_start2`,
call each individual functions inside `receive_start2` remotely, such as
`Remote.VDI.create`, and these SMAPIv2 functions will still be
multiplexed on the destiantion side, based on the destination SR type.
And this is indeed what we want, imagine a case where we are migrating
v1 -> v3, what we want is still create a snapshot VDI, but on the v3 SR.
This does mean that the state tracking, such as `State.add`, which was
previously tracked by the destination host, now needs to be tracked by
the source host. And this will affect a number of other `receive_`
functions such as `receive_finalize2` and `receive_cancel2`, which are
updated accordingly.
For backwards compatability reasons, we still need to preserve
`receive_start` which might still be called from an older host trying to
do a v1 -> v1 migration. And this is done by making sure that the
SMAPIv2 done inside `receive_start` are all local, while the
`receive_start` call itself is remote.
Signed-off-by: Vincent Liu <[email protected]>
0 commit comments