> 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

Reply via email to