| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
think.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx
pgplUdYq6hcbz.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home