WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)

To: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)
From: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 03 Jul 2006 16:40:30 +0100
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Julian Chesterfield <julian.chesterfield@xxxxxxxxxxxx>, NAHieu <nahieu@xxxxxxxxx>, Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>, Dan Smith <danms@xxxxxxxxxx>
Delivery-date: Mon, 03 Jul 2006 08:41:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1151938599.4785.14.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D4BAB1A@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <m3psh3pm7t.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1151674861.7893.5.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <m3hd22ramh.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1151696271.7893.21.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1151928154.7699.3.camel@xxxxxxxxxxxxxxxxxxxxx> <1151938599.4785.14.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2006-07-03 at 15:56 +0100, Stephen C. Tweedie wrote:
> Hi,
> 
> On Mon, 2006-07-03 at 13:02 +0100, Harry Butterworth wrote:
> 
> > > 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.
> 
> Right, you just made the point I was making --- you've introduced
> dependency on a new hypothetical fault-tolerant, cluster-aware device
> layer.  :-)

Yes, well I said we were going to need one of these about a year and a
half ago.  We should really have had it finished by now ;-P

> 
> In principle, with the right software, and configuring your entire
> infrastructure from scratch, this sort of device-based mechanism may
> work very well.

Yes. It does. Here's one we prepared earlier:
http://www-03.ibm.com/press/us/en/pressrelease/19705.wss

> But today, with my existing storage already set up, the only way I can
> easily add Xen migration capabilities to my network, taking advantage of
> the existing storage server I have, is to use NFS from that server.  I
> just don't have any block-level SAN configured.  *That* is why NFS is
> important --- not because it's necessarily the better choice, but that
> it's one of the configurations we can expect users to have already.
> 
> Conversely, for users with SANs already, whether running over iSCSI or
> FC or whatever, block-level migration will be needed.  It's a matter of
> being able to use existing solutions rather than mandating a new storage
> configuration.

I agree that it's generally most important to have solutions that work
now.  I'm just taking an opportunity to get people thinking about how to
solve the kind of problems exemplified by the block device migration
above; of which there are quite a few other examples in Xen.

> 
> --Stephen
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel