qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)


From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)
Date: Thu, 2 Jul 2009 03:30:27 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]