Re: [Qemu-devel] [RFC][PATCH v3 00/21] virtproxy: host/guest communication layer

[Michael Roth]

Wow, good catches. I'd simplified the examples with v2 and failed to 
correct some of the typos I introduced then when sending out v3. Your 
intuition is correct on most of these:

On 11/16/2010 03:57 PM, Stefan Hajnoczi wrote:
> On Tue, Nov 16, 2010 at 1:15 AM, Michael Roth<address@hidden>  wrote:
> Some basic questions from someone who has never used virtio-serial:
>
> > EXAMPLE USAGE:
> >
> > note: oforward/iforward chardev options have not yet been converted over from 
> > original standalone host daemon implementation so this won't work till then. 
> > The examples however have been updated for reference.
> >
> >   - Proxy http and ssh connections from a host to a guest over a virtio-serial 
> > connection:
> >     # start guest with virtio-serial. for example (RHEL6s13):
> >     qemu \
> >     -device virtio-serial \
> >     -chardev virtproxy,id=test0, \
> >              oforward=http:127.0.0.1:9080,oforward=ssh:127.0.0.1:22 \
> >     -device virtconsole,chardev=test0,name=test0 \
> >     ...
>
> Is virtconsole just a way of throwing something on the virtio-serial
> bus?  A quick peek at hw/virtio-console.c suggests "virtserialport"
> could also be used (and would be more intuitive because we don't want
> a console, just a serial port)?

Yup, that's supposed to be -device virtserial

> >     # in the guest:
> >     ./qemu-vp -c virtserial-open:/dev/virtio-ports/test2:- -i http:127.0.0.1:80 
> > \
> >               -i ssh:127.0.0.1:22
>
> name=test0 above.  Is this a typo or where does test2 come from?

Yup, should be /dev/virtio-ports/test0

> What does "virtserial-open" mean?  Why not
> virtio-serial:/dev/virtio-ports/test2 to match the "-device
> virtio-serial" above?  Virtio has a naming issue, every implementation
> names things slightly differently :).

I added a verb because I was trying to stick with the convention for the 
unix-(connect|listen)/tcp-(connect|listen) methods used in earlier 
versions of qemu-vp (when it was run in the host as well as the guest, 
and connected to/listen for data from a channel via a -chardev 
socket,... or direct tcp connection). Now that the host daemon has been 
replaced with a virtproxy chardev these actually don't have much use 
anymore, and the tcp support has been dropped entirely...

So just plain "isa-serial"/"virtserial" might be a bit more intuitive 
now, since now there's a clear mapping between the channel type we 
specify to qemu-vp and the -device used for the channel. I'll go ahead a 
make this change.

> >     # from host, access guest http server
> >     wget http://locahost:9080
> >     # from host, access guest ssh server
> >     ssh localhost -p 9022
>
> I don't see 9022 above, should it have been "oforward=ssh:127.0.0.1:9022"?

Yes :) I'll make sure fix these up for the next round. Thanks!

> Stefan