WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

[Xen-API] cross-pool migrate, with any kind of storage (shared or local)

To: "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-API] cross-pool migrate, with any kind of storage (shared or local)
From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Date: Wed, 13 Jul 2011 15:21:37 +0100
Accept-language: en-US
Acceptlanguage: en-US
Delivery-date: Wed, 13 Jul 2011 07:21:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxBaC011FXJzoDKQvqcwzxyufoOKw==
Thread-topic: cross-pool migrate, with any kind of storage (shared or local)
Hi,

I've created a page on the wiki describing a new migration protocol for xapi. 
The plan is to make migrate work both within a pool and across pools, and to 
work with and without storage i.e. transparently migrate storage if necessary.

The page is here:

http://wiki.xensource.com/xenwiki/CrossPoolMigration

The rough idea is to:
1. use an iSCSI target to export disks from the receiver to the transmitter
2. use tapdisk's log dirty mode to build a continuous disk copy program
-- perhaps we should go the full way and use the tapdisk block mirror code to 
establish a full storage mirror?
3. use the VM metadata export/import to move the VM metadata between pools

I'd also like to
* make the migration code unit-testable (so I can test the failure paths easily)
* make the code more robust to host failures by host heartbeating
* make migrate properly cancellable

I've started making a prototype-- so far I've written a simple python wrapper 
around the iscsi target daemon:

https://github.com/djs55/iscsi-target-manager

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api