qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: jvrao
Subject: Re: [Qemu-devel] [GSoC 2010] Pass-through filesystem support.
Date: Mon, 12 Apr 2010 08:16:58 -0700
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

Jamie Lokier wrote:
> Mohammed Gamal wrote:
>> 2- With respect to CIFS. I wonder how the shares are supposed to be
>> exposed to the guest. Should the Samba server be modified to be able
>> to use unix domain sockets instead of TCP ports and then QEMU
>> communicating on these sockets. With that approach, how should the
>> guest be able to see the exposed share? And what is the problem of
>> using Samba with TCP ports?
> 
> One problem with TCP ports is it only works when the guest's network
> is up :) You can't boot from that.  It also makes things fragile or
> difficult if the guest work you are doing involves fiddling with the
> network settings.
> 
> Doing it over virtio-serial would have many benefits.
> 
> On the other hand, Samba+TCP+CIFS does have the advantage of working
> with virtually all guest OSes, including Linux / BSDs / Windows /
> MacOSX / Solaris etc.  9P only works with Linux as far as I know.

Here is the list of 9p platforms

http://9p.cat-v.org/implementations

> 
> I big problem with Samba at the moment is it's not possible to
> instantiate multiple instances of Samba any more, and not as a
> non-root user.  That's because it contains some hard-coded paths to
> directories of run-time state, at least on Debian/Ubuntu hosts where I
> have tried and failed to use qemu's smb option, and there is no config
> file option to disable that or even change all the paths.
> 
> Patching Samba to make per-user instantiations possible again would go
> a long way to making it useful for filesystem passthrough.  Patching
> it so you can turn off all the fancy features and have it _just_ serve
> a filesystem with the most basic necessary authentication would be
> even better.
> 
> -- Jamie
> 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]