> -----Original Message----- > From: zfs-discuss-boun...@opensolaris.org > [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Tim Cook > Sent: Wednesday, August 11, 2010 8:46 PM > To: Edward Ned Harvey > Cc: ZFS Discussions > Subject: Re: [zfs-discuss] ZFS and VMware > > > > 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 >
This is not entirely correct either. You're not forced to use VMFS. You can format the LUN with VMFS, then put VM files inside the VMFS; in this case you get the Guest OS filesystem inside a VMDK file on the VMFS filesystem inside a LUN/ZVOL on your ZFS filesystem. You can also set up Raw Device Mapping (RDM) directly to a LUN, in which case you get the Guest OS filesystem inside the LUN/ZVOL on your ZFS filesystem. There has to be VMFS available somewhere to store metadata, though. It was and may still be common to use RDM for VMs that need very high IO performance. It also used to be the only supported way to get thin provisioning for an individual VM disk. However, VMware regularly makes a lot of noise about how VMFS does not hurt performance enough to outweigh its benefits anymore, and thin provisioning has been a native/supported feature on VMFS datastores since 4.0. I still think there are reasons why iSCSI would be better than NFS and vice versa. -Will _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
