CrossPoolMigrationv2: Difference between revisions
From Xen
Jump to navigationJump to search
Lars.kurth (talk | contribs) (Created page with "<!-- MoinMoin name: CrossPoolMigration --> <!-- Comment: --> <!-- WikiMedia name: CrossPoolMigration --> <!-- Page revision: 00000005 --> <!-- Original date: Mon Jul 1…") |
Lars.kurth (talk | contribs) mNo edit summary |
||
Line 4: | Line 4: | ||
<!-- Page revision: 00000005 --> |
<!-- Page revision: 00000005 --> |
||
<!-- Original date: Mon Jul 18 15:07:12 2011 (1311001632000000) --> |
<!-- Original date: Mon Jul 18 15:07:12 2011 (1311001632000000) --> |
||
{{TODO|Images and other attachments are missing!}} |
|||
__NOTOC__ |
__NOTOC__ |
||
This page describes a possible design for Cross-pool migration (which also works for within-pool migration with and without shared storage). |
This page describes a possible design for Cross-pool migration (which also works for within-pool migration with and without shared storage). |
||
This is an alternative design to |
This is an alternative design to [[CrossPoolMigrationV2]] |
||
This design has the following features: |
This design has the following features: |
Revision as of 17:15, 29 November 2011
This page describes a possible design for Cross-pool migration (which also works for within-pool migration with and without shared storage).
This is an alternative design to CrossPoolMigrationV2
This design has the following features:
- tapdisk log-dirty is used to build an efficient continuous disk copy program
- this is storage-format agnostic: it doesn't require .vhd
- the SM on one host can generate URIs which can be used by other SMs to access disks over iSCSI on the storage network
- handling of iSCSI endpoints (both initiators and targets) is abstracted by an iSCSI service
- this is expected to simplify the current code and prevent (eg) a bug in one SM plugin from interfering with another SM plugin
- a single codepath is used in xapi, making testing easier
- this replaces the existing migration API
- a simple RESTful API makes the whole thing quite easy to test, prod etc.
- the xapi pieces and the SM pieces can be developed and tested independently and integrated at the end
Component diagram
Media:CrossPoolMigration$components.pdf
Migration sequence
Media:CrossPoolMigration$migrate.pdf
Proposed milestones and task list
The following milestones are proposed:
Milestone number |
1 |
2 |
3 |
4 |
The following tasks are proposed:
Task | Status |
Forward-port blktap1 log dirty mode to tapdisk2 | |
Implement an iSCSI service in dom0 | Completed |
Modify VDI.deactivate to finish any pending copies | |
Implement xapi HTTP operations | |
Create a continuous copy program (use sparse_dd?) | |
Implement SMAPI VDI.copy | |
Implement SMAPI VDI.get_url | |
Implement XenAPI VM.migrate, VM.receive | |
Implement xapi HTTP heartbeat |
Links
The iscsi-target-manager is a simple python program which wraps the "tgtadm" commands used to configure an iSCSI target.