From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ewan Mellor Subject: Re: An Introduction to the Xen-API Work Date: Wed, 8 Nov 2006 18:45:56 +0000 Message-ID: <20061108184556.GD32530@leeni.uk.xensource.com> References: <20061104152907.GD28706@leeni.uk.xensource.com> <4552221D.1080705@egenera.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4552221D.1080705@egenera.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Patrick O'Rourke Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On Wed, Nov 08, 2006 at 01:29:49PM -0500, Patrick O'Rourke wrote: > Ewan Mellor wrote: > > > o xm suspend - Save a VM to a location under Xend's management > > o xm resume - Resume a VM from that same location > > Does this preclude running Xen in an environment with no persistent > storage? For example we now suspend to pipe which actually results in > the suspend image being stored off the Xen host. We've not taken xm save and xm restore away, so you can still use them if you know what you're doing. We're trying to encourage people not to do that, because of the non-obvious (but very real) risk to their data, but if it's integrated into a wider protective framework, then that's fine of course. Would you like an API call that better supported this use-case? In the long run, might your integration be easier if Xend supported "save to this address/port" or something like that? Ewan.