Open Stack

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-gaaf at bisect.de>
>>> To: "Deepak Shetty" <dpkshetty at gmail.com>
>>> Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>,
>>> ceph-devel at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev