CP-312361 [Design doc] SXM V3 support#7109
Conversation
LunfanZhang
force-pushed
the
private/luzhan/sxm-v3-design
branch
3 times, most recently
from
e6b7031 to
51e8bb9
Compare
LunfanZhang
force-pushed
the
private/luzhan/sxm-v3-design
branch
from
51e8bb9 to
2b1ebfa
Compare
LunfanZhang
force-pushed
the
private/luzhan/sxm-v3-design
branch
from
2b1ebfa to
a079ca8
Compare
| VHD backend, and the whole similar_content / content_id matching depends on it. SMAPIv3 uses qcow2 instead of VHD, so there is no vhd-parent to read, and the chain cannot be rebuilt | ||
| the same way. Adding a vhd-parent field for SMAPIv3 is also a bad fix: it would push a storage-internal detail up into XAPI, which is something the storage layer is meant to hide. So | ||
| the similar_content + content_id + vhd-parent path does not work for SMAPIv3, and it also breaks the layering. That is why we mirror the tree directly instead. | ||
|
|
There was a problem hiding this comment.
Maybe mention that an alternative would be to store the parent-child relationship in the plugin's database and expose it via Volume.stat. So we avoid the layering violation of "vhd-parent". However, reading the chain is one thing but redo the links on the destination will probably require a new function Volume.set_parent or something like that. Your approach looks cleaner to me.
There was a problem hiding this comment.
XAPI already knows the snapshot hierarchy; this is evident from the UI's ability to query XAPI and display the VM's snapshot tree. so, adding new fields to Volume.stat or impl a new API Volume.set_parent is variant of adding a "vhd-parent" key.
There was a problem hiding this comment.
Yes. My point was just to add a line specifying that the solution is possible but wasn't chosen. The idea is to prevent someone from asking later on, 'Why didn't you do it this way or that way?' But maybe a design doc isn't the right place for that.
|
Hi @minglumlu @psafont @gthvn1 @last-genius , if no further comments, would you mind approval PR? |
|
|
||
| ### Walking through the migration | ||
|
|
||
| Migration runs in four phases. We describe each in terms of the example |
There was a problem hiding this comment.
Can we have some properties that need to hold during the migration, please? This helps contextualize the decisions behind the design, and aid the testability of it
For example:
- On failed migration, none of the VDIs must be present in the destination host
- On successful migration, none of the VDIs must remain on the origin host
- On successful migration the relationship of the VDIs must be kept at the destination host
There was a problem hiding this comment.
Yes, I have added into the end of phase 4.
Signed-off-by: Lunfan Zhang （张伦凡） <lunfan.zhang@citrix.com>
LunfanZhang
force-pushed
the
private/luzhan/sxm-v3-design
branch
from
a079ca8 to
23ea9b2
Compare
5 participants
No description provided.