On Tue, Jun 5, 2012 at 8:29 AM, Whit Blauvelt <whit.gluster at transpect.com>wrote: > On Tue, Jun 05, 2012 at 08:13:37AM -0700, Anand Avati wrote: > > > Whit, > > There has been no drop in goal. There are many parts to "supporting a VM > > workload". The goals listed for 3.3 are definitely met - to make VMs > work good > > enough (fix self-heal locking issues, some FUSE upstream work for > supporting > > O_DIRECT etc.) However, for 3.4 we have bigger goals of supporting VM > image use > > case in a much better way - libglusterfsclient integration for QEMU etc. > This > > was what Amar was referring to. I hope I clarified your doubt, and > apologies > > for the confusion. > > Thanks for the clarification, Avanti. So if "VMs work good enough" now, the > recommendation is that in general Gluster is ready for production work with > VMs? Performance should be acceptable, if not always spectacular? Or should > VM use be considered more in the beta area still, until 3.3.1 or whatever? > > I know there's no substitute for testing it in a particular environment. > Just trying to get the general overview before committing to that. > > You are definitely expected and encouraged to test out VMs in a test environment. This is the first public release with the announced VM support and there is only so much what internal QA can cover. While there are no known issues, we are actively awaiting feedback from all your beta testing. About performance - FUSE is something which will be a fundamental limit to how much performance you get expect for a VM image. Whether that is good enough for you or not is something only you can decide. We have heard many users say they are very satisfied. Some might not be. The libglusterfsclient based QEMU integration is for this very purpose of avoiding context switches you get with a FUSE filesystem. That would however be an add-on, and FUSE mount based VM image will still work. Avati -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20120605/13f1796e/attachment-0001.htm>