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


Re: [Xen-devel] A migration framework for external devices

To: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] A migration framework for external devices
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Thu, 09 Feb 2006 11:37:18 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Ronald Perez <ronpz@xxxxxxxxxx>, "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 09 Feb 2006 16:49:01 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OF70690E95.8D137B5E-ON85257110.004FEFF1-85257110.0059C259@xxxxxxxxxx>
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>
References: <OF70690E95.8D137B5E-ON85257110.004FEFF1-85257110.0059C259@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (Macintosh/20051201)
Stefan Berger wrote:
Also what the plugins would need to do is lock the system so that once the migration of VM A is starting no other migrated virtual machine B has altered the state into a contradictory state that prevents migration of A. I think one of the aspects of migration is to look at the target system first and see whether one can migrate into it, then lock it to its state (or do that at the same time) and then start the migration. Basically migration needs to be 'atomic'.

Yes this is the key point. With the framework in place it would be a nice thing to do "dry runs" on the target. That is, do everything but actually migrate the domain. That way you could check that all the devices can be configured correctly, etc. In other words, verify the platform ahead of time. Get a high confidence in the target before attempting the migration.

I would have let the plugins implement their own protocol that suits their needs and the framework just provides a lower level transport protocol for dispatching messages to the plugins. At least that was my initial thinking. Not sure whether RPC is necessary here.

Yeah, I'm not sure either the more I consider things. If it can save time and work, I'm for it.


Xen-devel mailing list