On Wed, Aug 11, 2010 at 7:27 PM, Edward Ned Harvey <sh...@nedharvey.com>wrote:
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > > boun...@opensolaris.org] On Behalf Of Paul Kraus > > > > I am looking for references of folks using ZFS with either NFS > > or iSCSI as the backing store for VMware (4.x) backing store for > > I'll try to clearly separate what I know, from what I speculate: > > I know you can do either one, NFS or iscsi served by ZFS for the backend > datastore used by ESX. I know (99.9%) that vmware will issue sync-mode > operations in both cases. Which means you are strongly encouraged to use a > mirrored dedicated log device, presumably SSD or some sort of high IOPS low > latency devices. > > I speculate that iscsi will perform better. If you serve it up via NFS, > then vmware is going to create a file in your NFS filesystem, and inside > that file it will create a new filesystem. So you get twice the filesytem > overhead. Whereas in iscsi, ZFS presents a raw device to VMware, and then > vmware maintains its filesystem in that. > > > That's not true at all. Whether you use iSCSI or NFS, VMware is laying down a file which it presents as a disk to the guest VM which then formats it with its own filesystem. That's the advantage of virtualization. You've got a big file you can pick up and move anywhere that is hardware agnostic. With iSCSI, you're forced to use VMFS, which is an adaptation of the legato clustered filesystem from the early 90's. It is nowhere near as robust as NFS, and I can't think of a reason you would use it if given the choice; short of a massive pre-existing investment in Fibre Channel. With NFS, you're simply using ZFS, there is no VMFS to worry about. You don't have to have another ESX box if something goes wrong, any client with an nfs client can mount the share and diagnose the VMDK. --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
