On Fri, Oct 22, 2010 at 6:43 PM, Michael Roth <mdr...@linux.vnet.ibm.com> wrote: > OVERVIEW: > > Virtproxy proxies and multiplexes socket streams over a data channel between > a host and a guest (currently network connections, emulated serial, or > virtio-serial channels are supported). This allows for services such as guest > data collection agents, host/guest file transfer, and event > generation/handling to be implemented/deployed as basic socket-based daemons, > independently of the actual data channel. > > This code is intended to provide a channel-independent abstraction layer for > communicating with a QEMU-specific guest agent (in particular, the virtagent > RPC guest agent which will follow this in a seperate patchset), but may have > general utility beyond this (for instance: ssh/sftp/other guest agents/etc > over isa/virtio serial), and so is submitted here as a seperate patchset. > > Currently this communication involves 2 daemons (common code): 1 in the > guest, and 1 in the host. Each end multiplexes/demultiplexes/proxies > connections from the other end. In the future we hope to integrate the host > component directly into qemu as a chardev. > > BUILD/USAGE INFO: > make qemu-vp > ./qemu-vp -h > > EXAMPLE USAGE: > > - 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 socket,path=/tmp/test0-virtioconsole.sock,server,nowait,id=test0 \ > -device virtconsole,chardev=test0,name=test0 \ > -chardev socket,path=/tmp/test1-virtio-serial.sock,server,nowait,id=test1 \ > -device virtserialport,chardev=test1,name=test1 \ > -chardev socket,path=/tmp/test2-virtio-serial.sock,server,nowait,id=test2 \ > -device virtserialport,chardev=test2,name=test2 \ > ... > # in the host: > ./qemu-vp -c unix-connect:/tmp/test2-virtio-serial.sock:- -o > http:127.0.0.1:9080 \ > -o ssh:127.0.0.1:9022 > # 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 > > # from host, access guest http server > wget http://locahost:9080 > # from host, access guest ssh server > ssh localhost -p 9022 > > - Proxy http and ssh connections from a host to a guest over a network > connection: > # start guest with network connectivity to host > # in the guest: > ./qemu-vp -c tcp-listen:<guest_ip>:9000 -i http:127.0.0.1:80 \ > -i ssh:127.0.0.1:22 > # in the host: > ./qemu-vp -c tcp-connect:<guest_ip>:9000 -o http:127.0.0.1:9080 \ > -o ssh:127.0.0.1:9022 > ... > > By specifying -i and -o options in the host and guest, respectively, the > channel can also be used to establish connections from a guest to a host. > > KNOWN ISSUES: > > - Deadlocking the guest: In tests over isa-serial ports I've hit cases where > the chardev (socket) on the host-side seem to fill up the buffer, likely due > to qemu rate-limiting data in accordance with the port's baud rate (which may > explain why i hadn't seen this with network-based or virtio-serial data > channels.
QEMU does not perform any rate limiting.
