From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMC4J-00046y-KI for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:30:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMC4F-0003wv-2X for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:30:35 -0400 Received: from [199.232.76.173] (port=43605 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMC4E-0003wY-Uw for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:30:30 -0400 Received: from mail2.shareable.org ([80.68.89.115]:50812) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MMC4E-0005p1-HQ for qemu-devel@nongnu.org; Wed, 01 Jul 2009 22:30:30 -0400 Date: Thu, 2 Jul 2009 03:30:27 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) Message-ID: <20090702023027.GC18372@shareable.org> References: <20090701162114.GB24296@redhat.com> <4A4B91F7.9010206@redhat.com> <20090701165039.GF24296@redhat.com> <4A4B9D2F.5000607@redhat.com> <4A4BB038.7050401@codemonkey.ws> <4A4BBBE6.2070601@redhat.com> <4A4BC01B.7000100@codemonkey.ws> <4A4BCD80.2000906@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4BCD80.2000906@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Gerd Hoffmann wrote: > vm running at your workstation in the office, with -serial tcp. You are > heading home, leaving telnet connected. At home you'll find you want to > check something in your vm via vpn. > > With current qemu: You have to zap the telnet session somehow to be > able to connect. > > With switching: You have to talk to the monitor to reconfigure things. > > With multiple connections and multiplexing: You'll just connect, type a > few commands, disconnect, done. You'll even see what you have done when > you come back to the office the next day. You should have run telnet inside GNU screen :-) Or since you have VNC, VNC to your desktop instead of the guest :-) > Monitor is different for two reasons: > > First, we could actually open a new session. That wouldn't work for > serial as we can't hotplug a serial line into the guest on connect. virtio-serial/vmchannel... It could handle that if we wanted to. If nothing else, as a hotplug PCI serial port, and let the guest's udev attach a getty. I doubt anyone would bother, but perhaps if it's useful for last-resort guest recovery. > Second, if the monitor is used by libvirt or some other management app a > second connection to the same session is seriously harmful. Quite so! Right now, I deal with this (with a different management app) by the exciting method of a qemu monitor proxy written in Perl, which multiplexes multiple monitor client sessions onto QEMU's single session. It works quite well. -- Jamie