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" <[email protected]>
To: "Deepak Shetty" <[email protected]>
Cc: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>,
[email protected]
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
