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


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

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)
From: Dan Smith <danms@xxxxxxxxxx>
Date: Sat, 01 Jul 2006 07:22:06 -0700
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Jerone Young <jyoung5@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Julian Chesterfield <julian.chesterfield@xxxxxxxxxxxx>, NAHieu <nahieu@xxxxxxxxx>, Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>
Delivery-date: Sat, 01 Jul 2006 07:22:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200607010136.07076.mark.williamson@xxxxxxxxxxxx> (Mark Williamson's message of "Sat, 1 Jul 2006 01:36:06 +0100")
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> <m3sllmpfvj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1151705722.2570.5.camel@xxxxxxxxxxxxxxxxxxxxx> <200607010136.07076.mark.williamson@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MW> Well, it doesn't really matter what the destination dom0 is using
MW> as block devices provided the node name doesn't have to stay the
MW> same on the destination machine - and if you use the hotplug
MW> scripts to set up block devices then it doesn;t.

Right, exactly.

MW> I think being able to demand-fault virtual disks across would be
MW> quite cool (with the copy eventually completing in the background,
MW> eliminating the origin as a point of failure.  For smaller, or
MW> more ad-hoc setups this could be quite useful (especially if you
MW> had a daemon trickle updates across the network continuously at
MW> low bandwidth to minimise the diffs during migration)

This is the exact situation I had in mind.  I think it would be
extremely cool to have a peer-to-peer block migration mechanism, which
would allow the convenience of files for migration and the speed of
block devices.  You could even have a method for migrating block
images between machines, independent of a migration.  Imagine
something like:

  lvmcp /dev/vols/foo othermachine:/dev/vols

I think that would be neat.  It's rather straightforward too, I

Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx

Attachment: pgplUdYq6hcbz.pgp
Description: PGP signature

Xen-devel mailing list