From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57422 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIU0f-0005mt-Sa for qemu-devel@nongnu.org; Tue, 16 Nov 2010 17:28:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIU0e-0001ga-9c for qemu-devel@nongnu.org; Tue, 16 Nov 2010 17:28:17 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:51773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PIU0e-0001gT-5e for qemu-devel@nongnu.org; Tue, 16 Nov 2010 17:28:16 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oAGMBC14014919 for ; Tue, 16 Nov 2010 17:11:12 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oAGMSF3q2195514 for ; Tue, 16 Nov 2010 17:28:15 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oAGMSEuI013476 for ; Tue, 16 Nov 2010 17:28:15 -0500 Message-ID: <4CE3057C.40501@linux.vnet.ibm.com> Date: Tue, 16 Nov 2010 16:28:12 -0600 From: Michael Roth MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v3 00/21] virtproxy: host/guest communication layer References: <1289870175-14880-1-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: agl@linux.vnet.ibm.com, abeekhof@redhat.com, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, amit.shah@redhat.com 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 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