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-devel

Re: [Xen-devel] Xen and migration

To: Jacob Gorm Hansen <jg@xxxxxx>
Subject: Re: [Xen-devel] Xen and migration
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 02 Oct 2003 22:25:38 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Thu, 02 Oct 2003 22:26:44 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 02 Oct 2003 22:53:24 +0200." <20031002205324.GA16522@xxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> last year myself and a friend implemented the NomadBIOS system, a
> microkernel-based project similar in ambition to Xen, but with the
> ability to migrate guests quickly between host-machines. 
> 
> Do you plan to implement guest migration in Xen, or do you see any
> reasons why it might be difficult to do?

It's on our list of things to do, but haven't quiet got around to.

Our plan is to have the code that does the suspend/resume run in
domain 0 (the privileged domain), where it can memory map the
physical memory of other domains to read/write, and has easy
access to the disk/network etc.

The one complication with doing this on Xen is that since we
deliberately expose real resources, it's likely that the set of
physical 'machine' pages available to the domain when it is
resumed will be different from when it was suspended.

Hence, we need to re-write the OS's page tables to reflect the
change. This is actually quite straight forward since Xen already
needs to track which pages contain page directories/tables.

However, it's also necessary to update the OS's "mem_map"
structure (or equivalent) to reflect the new 'physical' to
'machine' page mapping.  This is obviously highly OS specific. We
could do this with a simple stub function in the OS, or we could
make the domain0 'resume' program OS specific. We haven't decided
which approach we prefer.  Having some some limited co-operation
from the guest OS in suspend/resume is quite sensible anyway, as
you need it to rerun DHCP etc anyway.

We'd probably modify the guest OS to cause it to evict the entire
buffer cache before asking for a suspend, to minimize the state.

Volunteers welcome ;-)

Cheers,
Ian


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>