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] of cows and clones: creating domains as clones of saved stat

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] of cows and clones: creating domains as clones of saved state
From: Peri Hankey <mpah@xxxxxxxxxxxxxx>
Date: Thu, 25 Nov 2004 15:01:18 +0000
Delivery-date: Thu, 25 Nov 2004 20:13:27 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <41A1DEBD.6060002@xxxxxxx>
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>
References: <E1CVA5S-000516-00@xxxxxxxxxxxxxxxxx> <41A1DEBD.6060002@xxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
Xen can already save the state of an established domain and restore it (in theory at least - so far it crashes for me). It seems to me that most of the objectives discussed for a copy-on-write memory system can be achieved by providing a mechanism for creating domains by cloning them from an initial state that is shared read-only between them with a copy-on-write mapping for each.

In this scheme a collection of clone domains can be created by starting from the saved state X of some original domain, which may be configured specifically for this purpose. The saved state X encapsulates the memory and filesystem state of the originating domain. The memory and filesystem components of the state X are shared read-only between the clone domains of X, with each clone domain superimposing its own copy-on-write mapping of the memory and filesystem states

When a clone domain is started, it immediately reconfigures itself as a distinct independent domain by writing its own configuration data to the copy-on-write mapping of its initial memory and filesystem state.

Once it has reconfigured itself, the state of a clone domain is the state represented by the the copy-on-write mapping of its private data as an overlay on the shared state from which it was first created.

This scheme has the added merit that creating a new domain of a particular kind is simply a matter of creating a new clone domain and reconfiguring it as an independent domain. Creating a new domain should take not much longer than restarting a migrating domain in a different machine.

Once it has reconfigured itself as an independent domain, each clone domain operates in the same way as any other domain. In particular, each has a fixed allocation of memory pages, but these are available to it over and above the pages that it shares read-write with other clones of the same initial state.

As far as I can see, the only mechanism that is required from xen is a mechanism for sharing memory pages read-only between domains with a copy-on-write mapping for each domain. It may be that the copy-on-write part of this mechanism is best handled by each guest operating system, although it would obviously be best to provide that as a service of the xen system itself.

There is an implied requirement that a clone domain created from a state X can only migrate to a machine where the the shared state X is available.

Peri Hankey

SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
Xen-devel mailing list