|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] of cows and clones: creating domains as clones of saved stat
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.
Regards
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
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] copy on write memory, (continued)
- Re: [Xen-devel] copy on write memory, Peri Hankey
- Re: [Xen-devel] copy on write memory, Jacob Gorm Hansen
- Re: [Xen-devel] copy on write memory, Keir Fraser
- Re: [Xen-devel] copy on write memory, Jacob Gorm Hansen
- Re: [Xen-devel] copy on write memory, Keir Fraser
- Re: [Xen-devel] copy on write memory, Jacob Gorm Hansen
- [Xen-devel] of cows and clones: creating domains as clones of saved state,
Peri Hankey <=
- Re: [Xen-devel] of cows and clones: creating domains as clones of saved state, Keir Fraser
- Re: [Xen-devel] of cows and clones: creating domains as clones of saved state, Peri Hankey
- Re: [Xen-devel] of cows and clones: creating domains as clones of saved state, Ian Pratt
- Re: [Xen-devel] of cows and clones: creating domains as clones of saved state, Keir Fraser
- Re: [Xen-devel] copy on write memory, Adam Heath
Re: [Xen-devel] copy on write memory, Adam Heath
|
|
|
|
|