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: "Dan Smith" <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)
From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date: Tue, 4 Jul 2006 17:48:11 -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:48:34 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YDt/1gYqt+Z+Q0eiH18Bzmlx58sbLgxBzLU90RDMO90V4i8JlkxVuD+dboCQ309Yxb2XIydf/7f5ke76cJlIH5KdLG9eifFg9bLRSLqdKQoaeBJ5Bz+ELGe6NxmqdC3hTK7z0UMRW0qrHhtls5GSvt5bN4lbiQ7wKThblweytqY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <m3k66sq4ni.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <m3k66sq4ni.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

Sure, local caching certainly makes sense here and I think there's
plenty of room to demonstrate benefit with using, but not depending
on, local disk.

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.

The concern that I have heard to motivate NFS is that vmware (and to a
lesser degree virtual server) have effectively trained administrators
to expect to manage VMs as image files (with vmdk/vhd).  So people
understand how to configure NFS, and they understand how to
backup/snapshot/dup images using unix 'cp'.  It's a largely
non-technical concern, and I agree that you could do cunning FS hacks
to achieve the same sort of interface to LUNs or LVM volumes.  Still,
a lot of enterprise admins seem to be very attached to NFS, and a
FS-level interface to their images and already have a lot of
home-baked-goods to interact with them that way.  To punctuate this
(and somebody please correct me if this is inaccurate...) I think that
VMware have only just started supporting iSCSI in the recent release
of esx/infrastructure -- so across the boards of enterprise installs
this is all reasonably new ground for existing users.


Xen-devel mailing list