From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C31bS-0001WZ-GF for qemu-devel@nongnu.org; Thu, 02 Sep 2004 20:06:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C31bQ-0001WN-NX for qemu-devel@nongnu.org; Thu, 02 Sep 2004 20:06:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C31bQ-0001WK-Kr for qemu-devel@nongnu.org; Thu, 02 Sep 2004 20:06:52 -0400 Received: from [216.254.0.202] (helo=mail2.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1C31Vw-0004tS-ES for qemu-devel@nongnu.org; Thu, 02 Sep 2004 20:01:12 -0400 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) ([64.81.88.222]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Sep 2004 00:00:37 -0000 Subject: Re: [Qemu-devel] Feature request: integrated smb server? From: "John R. Hogerhuis" In-Reply-To: References: Content-Type: text/plain Message-Id: <1094169680.12595.202.camel@aragorn> Mime-Version: 1.0 Date: Thu, 02 Sep 2004 17:01:20 -0700 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Thu, 2004-09-02 at 16:21, David E.Still wrote: > what would it take to integrate a small smb server intoqemu's > networking code? A lot. Having implemented a NetBT stack and read a lot about SMB in a past life, there's no such thing as a small SMB server; it's a complex layered set of protocols. You would have to integrate Samba if you really wanted to do this feasibly. Curious, what is your need? As you say, most OS's can mount and expose SMB shares. That means that the guest can already do what you want. Why not just expose an SMB share in the guest and mount it over the network? VmWare's integrated SMB server is one of the bits of evil in it; I've had issues with VmWare's various services that it installs interfering with the real thing... The argument you could make for such a feature is zero setup to do. Just start the guest, and QEMU exposes the file transfer service. The guest doesn't know anything about it. The user doesn't have to set anything up. > beable to write and *install* to the host system. I'm not suggesting What do you mean by install? Don't installers usually have to access the registry? There was a thread a little while back that discusses your suggestion. Fabrice decided that FTP was the way to go over HTTP or SMB, since it is simple and clients are readily available. One thing to understand is that the last mile to the guest's disk is a tricky thing. Operating systems tend to make the assumption that they have exclusive access to filesystems they have mounted. So read-only access is probably the best you can hope for without living very dangerously. On Windows, if you really want to be able to write to the host file system, you should probably go through SMB to do it. Then all the authentication, arbitration, perimissions, decryption, etc. is done by the host OS. And if you believe that, then you have to set up an SMB client to talk to Window's SMB server anyway. So embedding an SMB server wouldn't save any work. Of course there could be simplifying assumptions I'm missing that could take SMB out of the equation. I'm interested to hear those from others... -- John.