> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Jim Klimov > > I guess Richard was correct about the usecase description - > I should detail what I'm thinking about, to give some illustration.
After reading all this, I'm still unclear on what you want to accomplish, that isn't already done today. Yes I understand what it means when we say ZFS is not a clustering filesystem, and yes I understand what benefits there would be to gain if it were a clustering FS. But in all of what you're saying below, I don't see that you need a clustering FS. > of these deployments become VMWare ESX farms with shared > VMFS. Due to my stronger love for things Solaris, I would love > to see ZFS and any of Solaris-based hypervisors (VBox, Xen > or KVM ports) running there instead. But for things to be as > efficient, ZFS would have to become shared - clustered... I think the solution people currently use in this area is either NFS or iscsi. (Or infiniband, and other flavors.) You have a storage server presenting the storage to the various vmware (or whatever) hypervisors. Everything works. What's missing? And why does this need to be a clustering FS? > To be clearer, I should say that modern VM hypervisors can > migrate running virtual machines between two VM hosts. This works on NFS/iscsi/IB as well. Doesn't need a clustering FS. > With clustered VMFS on shared storage, VMWare can > migrate VMs faster - it knows not to copy the HDD image > file in vain - it will be equally available to the "new host" > at the correct point in migration, just as it was accessible > to the "old host". Again. NFS/iscsi/IB = ok. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
