Re: [Qemu-devel] [GSoC 2010] Pass-through filesystem support.

[jvrao]

Alexander Graf wrote:
> On 12.04.2010, at 13:58, Jamie Lokier wrote:
> 
>> Mohammed Gamal wrote:
>>> On Mon, Apr 12, 2010 at 12:29 AM, Jamie Lokier <address@hidden> wrote:
>>>> Javier Guerra Giraldez wrote:
>>>>> On Sat, Apr 10, 2010 at 7:42 AM, Mohammed Gamal <address@hidden> wrote:
>>>>>> On Sat, Apr 10, 2010 at 2:12 PM, Jamie Lokier <address@hidden> wrote:
>>>>>>> To throw a spanner in, the most widely supported filesystem across
>>>>>>> operating systems is probably NFS, version 2 :-)
>>>>>> Remember that Windows usage on a VM is not some rare use case, and
>>>>>> it'd be a little bit of a pain from a user's perspective to have to
>>>>>> install a third party NFS client for every VM they use. Having
>>>>>> something supported on the VM out of the box is a better option IMO.
>>>>> i don't think virtio-CIFS has any more support out of the box (on any
>>>>> system) than virtio-9P.
>>>> It doesn't, but at least network-CIFS tends to work ok and is the
>>>> method of choice for Windows VMs - when you can setup Samba on the
>>>> host (which as previously noted you cannot always do non-disruptively
>>>> with current Sambas).
>>>>
>>>> -- Jamie
>>>>
>>> I think having support for both 9p and CIFS would be the best option.
>>> In that case the user will have the option to use either one,
>>> depending on how their guests support these filesystems. In that case
>>> I'd prefer to work on CIFS support while the 9p effort can still go
>>> on. I don't think both efforts are mutually exclusive.
>>>
>>> What do the rest of you guys think?
>> I only noted NFS because most old OSes do not support CIFS or 9P -
>> especially all the old unixes.
>>
>> I don't think old versions of MS-DOS and Windows (95, 98, ME, Nt4?)
>> even support current CIFS.  They need extra server settings to work
>> - such as setting passwords on the server to non-encrypted and other quirks.
>>
>> Meanwhile Windows Vista/2008/7 works better with SMB2, not CIFS, to
>> properly see symlinks and hard links.
>>
>> So there is no really nice out of the box file service which works
>> easily with all guest OSes.
>>
>> I'm guessing that out of all the filesystems, CIFS is the most widely
>> supported in recent OSes (released in the last 10 years).  But I'm not
>> really sure what the state of CIFS is for non-Windows, non-Linux,
>> non-BSD guests.
> 
> So what? If you want to have direct host fs access, install guest drivers. If 
> you can't, set up networking and use CIFS or NFS or whatever.
> 
>> I'm not sure why 9P is being pursued.  Does anything much support it,
>> or do all OSes except quite recent Linux need a custom driver for 9P?
>> Even Linux only got the first commit in the kernel 5 years ago, so
>> probably it was only about 3 years ago that it will have begun
>> appearing in stable distros, if at all.  Filesystem passthrough to
>> Linux guests installed in the last couple of years is a useful
>> feature, and I know that for many people that is their only use of
>> KVM, but compared with CIFS' broad support it seems like quite a
>> narrow goal.
> 
> The goal is to have something simple and fast. We can fine-tune 9P to align 
> with the Linux VFS structures, making it really little overhead (and little 
> headache too). For Windows guests, nothing prevents us to expose yet another 
> 9P flavor. That again would be aligned well with Windows's VFS and be slim 
> and fast there.
> 
> The biggest problem I see with CIFS is that it's a huge beast. There are a 
> lot of corner cases where it just doesn't fit in. See my previous mail for 
> more details.
> 
As Alex mentioned, 9P is chosen for its mere simplicity and easy adaptability.
NFS and CIFS does not give that flexibility. As we mentioned in the patch 
series, we are 
already seeing better numbers with 9P. Looking ahead 9P can embed KVM/QEMU 
knowledge
to share physical resources like memory/cache between the host and the guest.

I think looking into the windows side of 9P client would be great option too. 
The current patch on the mailing list supports .U (unix) protocol and will be 
introducing
.L (Linux) variant as we move forward.

- JV


> 
> Alex
> 
> 
>