From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Domain save/migrate issue Date: Tue, 14 Feb 2006 08:55:39 -0600 Message-ID: <43F1EF6B.7010304@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Hand Cc: Noam Taich , xen-devel@lists.xensource.com, veillard@redhat.com List-Id: xen-devel@lists.xenproject.org Steven Hand wrote: >> I tend to agree, it's about having orthogonal APIs, I think you can build >> the current behaviour by a sequence of the simpler save and a destroy (though >> it would not be atomic anymore). Is there any strong reason a saved domain >> must not be left running ? >> > > Unless you also have some way to simulataneously snapshot the file > system, it is not safe to allow the guest to continue and then later > resume the checkpointed version. > There are storage devices that provide this capability. Also, Dan Smith is working on a COW device for Xen that could be used to checkpoint a storage device. However, there's a fair bit of work that would be needed to allow for light-weight checkpointing. A domain has to be suspended for the checkpoint to finish (although presumably one could use a similar as live migration to get most of the way there). Today, in Xen, there is no way to get out of a suspended state. If a domain could leave the suspended state, it would make checkpointing pretty cheap. Also, presumably, it would simplify rebooting because instead of having to recreate a domain on reboot, the hypervisor could just reinit it. Of course, it would need some way of knowing how to build the domain... Regards, Anthony Liguori > S. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >