> 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