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/
Home Products Support Community News


[Xen-devel] A migration framework for external devices

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] A migration framework for external devices
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Wed, 8 Feb 2006 15:16:37 -0500
Cc: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>, Ronald Perez <ronpz@xxxxxxxxxx>
Delivery-date: Wed, 08 Feb 2006 20:27:53 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx


 As part of our off-list discussion on how to migrate the virtual TPM in support of virtual machine migration (live migration), we came up with the idea of having a migration framework that could be used for general migration of 'external devices' such as disk images and possibly serialized state of device models. I was going to look into this now and was wondering whether a framework like this is the right approach, particularly since it would exist next to XenD, which I believe is handling live migration ?
 To be a bit clearer on the idea of the framework: It would consist of a deamon running on the target machine whose different plug-ins know how to handle the migration of different pieces of state information and know how to de-serialize them (which mere 'scp' would not do). Clients on the source machine would communicate with that daemon and transfer the state. The clients would have to be triggered by XenD after a partition is not scheduled anymore and be given the IP address of the target machine. Afterwards there needs to be some synchronization on resuming the scheduling on the target machine after all state has been deserialized.
  The plugable deamon itself would handle the communication sockets, a low-level protocol which the plugins and clients would use, have support for timing and protocol time-outs and provide threading. The plugins would have to do the rest of what's necessary to communicate with the infrastructure and the higher-level protocol shared with the clients.

Xen-devel mailing list