| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)
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.
a.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home