[Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

[Jan Marten Simons <marten@xtal.rwth-aachen.de>]

Ok, I talked about this issue in irc lately, but as this list will have
a larger audience I'll post this here as well. So here is the (cleaned) log:


What I want:

<jamasi> some feature I'm really missing is: a v(S)FTP sever inside the
emulated network offering a local folder of the host for R/W-access.
<pbrook> If you have sshd running on the host, you can just connect to that.
<jamasi> win-hosts usually dont have sshd running. And it would be
really appreciated, if it would work with user-net.


An idea how this could be done:

*<jamasi> so basically you could just take some tiny ftp-server source
and put it into qemu and then add a command-switch for the directory to
share. username and psw could be qemu:qemu or even left blank.*


Why the current options are no real alternative so far (either
linux-only or read-only):

<MadMerlin> can't qemu do file sharing via samba already?
<iamlost> jamasi: it already exists.
<iamlost> jamasi: virtual disks
<pbrook> iamlost: THat's only readonly.
<iamlost> pbrook: virtual floppys or virtual cdroms could be used to
transfer data from host to guest while guest is running.
<pbrook> Like I said that's still only readonly.
<iamlost> pbrook: host could read virtual hard disk from guest to
transfer data in other direction
<pbrook> Huh?
<iamlost> pbrook: so, despite being readonly, it can be made two way
<pbrook> How do you do that?
<iamlost> pbrook: in linux, via lomount.
<iamlost> as long as u mount it read-only in the host, u shouldnt have
any problems.
<pbrook> And if you're on window, or don't have root access?
<pbrook> If you're on liux you probably already have sshd running, so
can just use sftp.
<iamlost> pbrook: im sure theres something similar (like Daemon Tools)
for windows...
<jamasi> I think the vvFat-approch is pretty nice, but it blocks an
ide-channel and it somehow feels more dangerous than a simple ftp-server.
<pbrook> iamlost: daemon tools only does cdroms.
<pbrook> There are third party lomount-like things, but they tend to be
use unfriendly, and not very well supported.
<iamlost> oh
<pbrook> And you still need admin access.
<iamlost> :/
<pbrook> Plus to do that you have to shut down the guest.
<iamlost> well...u can still use virtual floppies...
<pbrook> How?
<iamlost> works fine as long as data is small enough.
<iamlost> its a little painful to use tho.
<pbrook> Very paindul, and how exactly do you mount those on a windows host?
<iamlost> when the guest writes data to a virtual floppy and ejects it,
u then write the image onto a real floppy
<iamlost> and then read that
<iamlost> i know there are tools like rawwrite.exe which can do that.
<pbrook> Most new machines don't have floppy drives.
<pbrook> Plus it's painfully slow.

*<jamasi> I think introducing some ftp-server is far less pita.
alternatively a webDAV-server would be an option.*

<iamlost> jamasi: there was a tftp sever patch some time ago
<pbrook> ftp is certainly the lowest-common-denominator simplest option.
<jamasi> this was readonly, too.
<jamasi> I'm looking for a way to exchange data with the host, without
shutting-down the guest and without needing any special conditions for
the host.
<jamasi> and for me an integrated ftp-server serving some host directory
seems like the best way to implement this.
<jamasi> sadly I'm really unskilled in c(++). Otherwise I'd try to
implement this.


So to implement the idea one would need to get the source of a tiny
gpl/bsd-ed FTP-server (does not need to have any fancy things like
usermanagement, SFTP or TFPT, ratio, quota,...), bind this to the
emulated gateway and create a new cmd-line-option to set the served
directory. A reread of the directory would be issued on a refresh-cmd
from the ftp-client on the guest.

Thanks for reading this. I'd really appreciate a patch for this
functionality, which should then be merged into cvs, imho, as this could
be an easy interface for fileexchange.

With regards,
Jan Simons