Change receive_start2 to multiplex on the local SR type
#6434
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Vincent-lau
force-pushed
the
private/shul2/sxm-mux4
branch
from
c696d49 to
0dd313b
Compare
psafont
reviewed
Apr 17, 2025
| @@ -569,6 +569,14 @@ module MIRROR : SMAPIv2_MIRROR = struct | |||
| Storage_migrate_helper.get_remote_backend url verify_dest | |||
| in | |||
| match remote_mirror with | |||
| | Mirror.QCOW2_mirror _ -> | |||
| (* this should never happen *) | |||
There was a problem hiding this comment.
This may not be the case if @gthvn1 gets away with it :)
There was a problem hiding this comment.
The type of the mirror is based on the SMAPI version reported by each storage backend (although they are currently hardcoded). So I don't think this will be an issue unless one changes the way mirroring is done in SMAPIv1... Feel free to modify this code in the future if needed though
robhoes
changed the title
reiceve_start2 to multiplex on the local SR typereceive_start2 to multiplex on the local SR type
robhoes
reviewed
Apr 23, 2025
robhoes
reviewed
Apr 23, 2025
robhoes
reviewed
Apr 23, 2025
|
|
||
| (* SMAPIv3 mirror operation *) | ||
| type operation = | ||
| | CopyV1 of copy_operation_v1 |
There was a problem hiding this comment.
Now the v's are getting confusing... But this seems to be defined in xapi-storage?
robhoes
approved these changes
Apr 23, 2025
Vincent-lau
force-pushed
the
private/shul2/sxm-mux4
branch
2 times, most recently
from
ead92ee to
efd1036
Compare
lindig
approved these changes
Apr 24, 2025
| raise | ||
| (Storage_error | ||
| (Migration_mirror_failure | ||
| "Incorrect remote mirror format for SMAPIv1" |
There was a problem hiding this comment.
Could more information be included to help diagnosis when this happens?
There was a problem hiding this comment.
This is a "this should never happen" branch and is only there to make the compiler happy... I don't think user should encounter this error in any case, and there is probably nothing they can do about it if they do for some reason...
Luckily we have a new SXM functional tests suite, which I am running to test for regressions. Looks good so far |
These will be used when mirroring a VDI that is on a SMAPIv3 SR. Signed-off-by: Vincent Liu <shuntian.liu2@cloud.com>
Adding a few more states that will be tracked by the send_state and receive_state. These will be used later on for SMAPIv3 outbound migration. We do need to give them a default value in case the deserialisation of the on-disk copy does not have these values. These are not used yet, so no functional change. Signed-off-by: Vincent Liu <shuntian.liu2@cloud.com>
These functions will not be exposed in storage_migrate.ml any more. `receive_start` is kept in the mux for backwards compatability reasons, and will go straight to the SMAPIv1 implemenetation. `receive_start2` calls will not be directed to the storage_mux any more, instead it will be multiplexed by the new layer in storage_migrate. Signed-off-by: Vincent Liu <shuntian.liu2@cloud.com>
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 <shuntian.liu2@cloud.com>
Vincent-lau
force-pushed
the
private/shul2/sxm-mux4
branch
from
efd1036 to
8da184b
Compare
|
Test LGTM, merge! |
github-merge-queue bot
pushed a commit
that referenced
this pull request
May 12, 2025
Continuation of #6434, more mutiplexing for SXM, this time the mirror status checking logic. No functional change. More to come...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Continuing on #6423
This PR changes the way
receive_start2is called, and it can now multiplex based on the source SR and destination SR type.Note that
receive_start2is introduced for inbound SXM for SMAPIv3, which is flagged off by default, so no need to worry about backwards compatability.Also introduces a couple of new types for SMAPIv3 migration, but they are uncurrently unused.
There should still be no functional change.
More to come...