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: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)
From: Dan Smith <danms@xxxxxxxxxx>
Date: Tue, 04 Jul 2006 17:25:21 -0700
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Julian Chesterfield <julian.chesterfield@xxxxxxxxxxxx>, NAHieu <nahieu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 04 Jul 2006 17:25:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <eacc82a40607041239m141c32a4t3692161fc72cf35f@xxxxxxxxxxxxxx> (Andrew Warfield's message of "Tue, 4 Jul 2006 12:39:07 -0700")
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> <1151941231.7699.18.camel@xxxxxxxxxxxxxxxxxxxxx> <eacc82a40607041239m141c32a4t3692161fc72cf35f@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
AW> I don't think that I see the immediate benefit of the lazy
AW> (migrate and fault blocks across on demand) block migration.  It
AW> doubles your exposure to failure (at least) and adds overhead.
AW> The only possible example I can think of is to very temporarily
AW> offload a VM that's gone heavily CPU bound onto an unloaded host.
AW> Is there a more obviously useful situation that I'm missing?

I think the immediate benefit is mostly as a "built-in" feature to
allow migration of VMs easily between machines that do not share
access to a centralized infrastructure.  Right now, if you want to do
that, you have to migrate the entire block device or file before you
can start the domain on the other side.  The lazy migration allows you
to get the domain started immediately.  It's probably not insanely
useful in an enterprise environment, but it would be a nice feature
for Xen to have, and I think it's possible that more enterprise
functionality could arise from developing the foundation.  Even if you
had a centralized block server, you could still benefit from the
abilities, by caching blocks locally in a local block device, such as
a hard disk.  The same infrastructure that provides the P2P lazy-copy
migration could be used to provide local caching, and probably more
interesting things.

I guess my initial comment was: I would think real enterprise people
would use iSCSI and a real SAN to provide access, instead of files on
NFS.  In that case, perhaps we can give more flexibility than the NFS
solution, with better performance.

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

Attachment: pgpehTyLYlomK.pgp
Description: PGP signature

Xen-devel mailing list