On 03/04/2015 09:33 AM, Danny Al-Gaaf wrote:
Am 04.03.2015 um 15:18 schrieb Csaba Henk:
Hi Danny,

----- Original Message -----
From: "Danny Al-Gaaf" <danny.al-g...@bisect.de>
To: "Deepak Shetty" <dpkshe...@gmail.com>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>,
ceph-de...@vger.kernel.org
Sent: Wednesday, March 4, 2015 3:05:46 PM
Subject: Re: [openstack-dev] [Manila] Ceph native driver for manila

...
Another level of indirection. I really like the approach of filesystem
passthrough ... the only critical question is if virtfs/p9 is still
supported in some way (and the question if not: why?).
That "only" seems to be a biggie, isn't it?
Yes, it is.

We -- Red Hat -- considered a similar, virtfs based driver for GlusterFS
but we dropped that plan exactly for virtfs being abandonware.

As far as I know it was meant to be a research project, and providing
a fairly well working POC it was concluded -- but Deepak knows more of
the story.
Would like to understand why it was abandoned. I see the need of
filesystem passthrough in the area of virtualization. Is there another
solution available?

Danny, I read through this thread and I wasn't sure I had anything to add, but now that it's gone quiet, I'm wondering what your plan is.

I wasn't aware that VirtFS is being considered "abandonware" but it did seem to me that it wasn't being actively maintained. After looking at the alternatives I considered VirtFS to be the best option for doing what it does, but it's applicability is so narrow that it's hard to find it appealing. I have the following problems with VirtFS: * It requires a QEMU/KVM or Xen hypervisor. VMware and HyperV have zero support nor any plans to support it. * It requires a Linux or BSD. Windows guests can't use it at all. Some googling turned up various projects that might give you a headstart writing a Windows VirtFS client, but we're a long way from having something usable. * VirtFS boils the filesystem down to the bare minimum, thanks to its P9 heritage. Interesting features like caching, locking, security (authentication/authorization/privacy), name mapping, and multipath I/O are either not implemented or delegated to the hypervisor which may or may not meet the needs of the guest application. * Applications designed to run on multiple nodes with shared filesystem storage tend to be tested and supported on NFS or CIFS because those have been around forever. VirtFS is tested and supported by nobody so getting application level support will be impossible.

The third one is the one that kills it for me. VirtFS is useful in extremely narrow use cases only. Manila is trying to provide shared filesystems in as wide a set of applications as possible. VirtFS offers nothing that can't also be achieved another way. That's not to say the other way is always ideal. If your use case happens to match exactly what VirtFS does well (QEMU hypervisor, Linux guest, no special filesystem requirements) then the alternatives may not look so good.

I'm completely in favor of seeing virtfs support go into Nova and doing integration with it from the Manila side. I'm concerned though that it might be a lot of work, and it might benefits only a few people. Have you found any others who share your goal and are willing to help?


Danny

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to