[Top][All Lists]

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

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional

From: Henrik Nordstrom
Subject: Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Date: Tue, 7 Jun 2005 23:45:40 +0200 (CEST)

On Mon, 6 Jun 2005, Jim C. Brown wrote:

Hmm...what if you don't have root/administrator access? It could still work if
you are determined enough, but thats not the sort of thing you want to force
onto a beginner.

Then write a suitable wrapper install package around a suitable small FTP daemon allowing beinners to set it up on a non-root port using user-net port redirection options to hide this for the guest.

Or spend some time on the generalised user-net pipe support mentioned earlier allowing the SMB suppor to be more easily configured/tailored.

FTP unfortunately doesn't fit in the user-net pipe framework due to it's (ftp) broken design (data channel mess).

HTTP could fit quite nicely in the pipe framework, but is't terribly useful as a general bi-directional exchange method due to client requirements..

SSH in theory could fit into the pipe framework, but lack of a suitable server-side which can run as non-root is somewhat hindering.

rlogin/rcp/rsh fits quite nicely in the pipe framework, with some small modifications on the server-side to allow them to run as non-root.

Thinking of it tftp should also fit very nicely in the user-net pipe framework, given a suitably relaxed tftp server..

Of course, that doesn't apply if you cant use SMB, as was this person's case.
(Does the SMB support in qemu even work on Windows hosts?)

The SMB glue is for all hosts except Windows. On Windows you have to use the native SMB filesharing.

In theory it may be possible to enable the SMB glue on Windows as well, but this requires a working Samba on Windows..

Giving the TFTP write access is probably the way to go (iirc this person would
have used TFTP in lieu of FTP, except that write access was required which made
TFTP a non-option).

Extending the existing TFTP code to also provide write access is higly preferable to adding a user-net FTP emulation in my eyes. Shouldn't be more than one or at most two screens of code.


reply via email to

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