From mboxrd@z Thu Jan  1 00:00:00 1970
From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
Subject: Re: [PATCH] Blktap: Userspace file-based image
	support.(RFC)
Date: Mon, 03 Jul 2006 13:02:34 +0100
Message-ID: <1151928154.7699.3.camel@localhost.localdomain>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D4BAB1A@liverpoolst.ad.cl.cam.ac.uk>
	<m3psh3pm7t.fsf@guaranine.beaverton.ibm.com>
	<1151674861.7893.5.camel@sisko.sctweedie.blueyonder.co.uk>
	<m3hd22ramh.fsf@guaranine.beaverton.ibm.com>
	<1151696271.7893.21.camel@sisko.sctweedie.blueyonder.co.uk>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <1151696271.7893.21.camel@sisko.sctweedie.blueyonder.co.uk>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Julian Chesterfield <julian.chesterfield@cl.cam.ac.uk>, NAHieu <nahieu@gmail.com>, Andrew Warfield <andrew.warfield@cl.cam.ac.uk>, Dan Smith <danms@us.ibm.com>
List-Id: xen-devel@lists.xenproject.org

On Fri, 2006-06-30 at 20:37 +0100, Stephen C. Tweedie wrote:
> Hi,
> 
> On Fri, 2006-06-30 at 07:17 -0700, Dan Smith wrote:
> > SCT> It depends on the environment.  To support cold/live migration,
> > SCT> having network-attached storage will be required; and file images
> > SCT> on NFS would be an extremely simple-to-setup way to achieve that.
> > 
> > Ah, but block devices can play too.  With dm-userspace, we could
> > migrate a domain from one machine to another, faulting the needed
> > blocks from its block devices on-demand, and copying the rest in the
> > background.  This would give us a peer-to-peer setup where block
> > devices could slowly move from machine to machine, following its
> > owner.  Once your block was accessed (or copied in the background),
> > it's local and fast.  A peer-to-peer NAS setup.
> 
> Could be useful in places, but it introduces a number of new
> dependencies.  The destination host now relies on the source host for
> data, so if the source crashes, you crash the destination too; and if
> you power-cycle, how do you track where in your cluster the latest copy
> of the block device is?

It's easy.  You run code to coordinate the mapping inside a
fault-tolerant virtual machine which persists across node failures and
cluster power cycles.

> 
> A true NAS solution isolates the Xen hosts from these problems.
> 
> --Stephen
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>