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<mdr...@linux.vnet.ibm.com> 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
