| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
Mike
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home