Repository navigation
CP-314918: design SMAPIv1 storage migration without tapdisk - #7366
MarkSymsCtx wants to merge 2 commits into
Conversation
Storage migration from an SMAPIv1 SR depends on tapdisk and VHD throughout, so qcow2 VDIs served by qemu-dp cannot be migrated in either direction. Propose letting SMAPIv1 SRs opt in, VDI by VDI, to the backend mirror SMAPIv3 already uses: an SR capability says the operations exist and the backend says which VDIs it mirrors, so products sharing the toolstack source can each choose. A backend mirror also needs to be cancellable, which the SMAPIv3 path lacks today. Signed-off-by: Mark Syms <mark.syms@citrix.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Please add additional reviewers as appropriate |
| - `args`: `[remote]`, an NBD URI of the form | ||
| `nbd+unix:///<export>?socket=<path>`. The backend connects to it as an NBD | ||
| client. | ||
| - Result: a string, the operation id. |
There was a problem hiding this comment.
The call will return without waiting for mirror complete. So that the operation id is recorded in send_table, right?
There was a problem hiding this comment.
Yes. vdi_mirror returns once the job is started or deferred, and the operation id is what xapi keeps in the send state ("Mirror send state for these VDIs stores the operation id, never a tapdisk", under What changes); wait_for_mirror then polls vdi_mirror_stat with it. I have added that to the vdi_mirror result in e3dda82 so the link is explicit.
| paused, so the v3 path finalises without knowing the mirror's last state. | ||
| This design requires SMAPIv1 backends to keep it and proposes the same for | ||
| SMAPIv3 plugins; that needs agreeing with the `feature/sxm-v3` work. | ||
| 2. **A per-VDI query or a published format.** The alternative is for xapi to |
There was a problem hiding this comment.
per-VDI query looks better to me. Otherwise, the storage backend would need to call back to XenAPI.
There was a problem hiding this comment.
Agreed. Publishing the format would mean SM writing image-format into sm_config and backfilling it at scan, which is the backend calling back into xapi; the query keeps the decision in the backend. e3dda82 moves this out of Open questions and into the Capability section as decided.
| apply to every VDI that takes it, not just to VDIs on SMAPIv3 SRs. | ||
| - `MigrateRemote.receive_finalize3` and `receive_cancel2` choose their | ||
| implementation from the source SR, like `choose_backend` today. With the | ||
| choice made per VDI, a VDI on an SMAPIv1 SR taking the backend mirror would |
There was a problem hiding this comment.
In case of old source + new destination, there is actually no choice at all. Can the existing logic on old source side drive the new destination side work correctly?
There was a problem hiding this comment.
I believe so. The backend choice for finalize and cancel is made on the source: MigrateRemote.receive_finalize3 and receive_cancel2 call choose_backend locally before calling the destination. So an old source always runs the tapdisk mirror and finalises it as one, which is consistent. Everything that must know the destination VDI is not served by tapdisk happens on the destination: its receive_start creates the leaf, and the import endpoint the old source connects to for that leaf's datapath is handled by the destination's own code, which with this design picks the import path from the attach result in DATA.import_activate. e3dda82 makes the "tapdisk mirror into a VDI served outside tapdisk" compatibility bullet say that an old source drives it unchanged. I have checked the source-side choice in the code; the destination half is what the design specifies, so please shout if you see the old source reaching the destination by a path that bypasses import_activate.
There was a problem hiding this comment.
It looks good to me so far. I think this part is tricky as its code logic in xapi basically can't change in order to support the backwards compatibility.
|
|
||
| ## Upgrade and compatibility | ||
|
|
||
| - An SM without `VDI_MIRROR_NBD`: xapi never calls the new operations. |
There was a problem hiding this comment.
I would think that an old pool can work with a SR which already contains qcow2 VDIs, although the pool just sees the VDIs in known format (raw and VHD).
There was a problem hiding this comment.
If you mean a remote pool SR that already contains qcow2 VDIs and accepting inbound migration from an older raw/vhd only SR, then yes.
There was a problem hiding this comment.
It depends on which part is old. With an older xapi and an SM that understands qcow2, yes: xapi never interprets the format, so the VDIs work normally and only storage migration is unavailable for them. I have reworded that bullet in e3dda82 so it does not read as if the pool cannot use them. An older SM is different: it does not recognise qcow2 VDIs at all (on LVM their QCOW- volumes match neither of its naming prefixes), so a pool running one will not see them. That is a downgrade constraint of the format rather than of this design, and I have added a line saying so.
Review on xapi-project#7366: the per-VDI mirror query is preferred to a published format, since publishing one would need the backend to write the format into xapi's database; an older source can drive the tapdisk mirror into a new destination unchanged; and an older xapi can still use qcow2 VDIs, losing only their storage migration. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Mark Syms <mark.syms@citrix.com>
Storage migration from an SMAPIv1 SR depends on tapdisk and VHD throughout, so qcow2 VDIs served by qemu-dp cannot be migrated in either direction. Propose letting SMAPIv1 SRs opt in, VDI by VDI, to the backend mirror SMAPIv3 already uses: an SR capability says the operations exist and the backend says which VDIs it mirrors, so products sharing the toolstack source can each choose. A backend mirror also needs to be cancellable, which the SMAPIv3 path lacks today.