Re: [vdsm] [RFC]about the implement of text-based console

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

 



> Itamar Heim píše v Čt 18. 10. 2012 v 20:32 +0200:
> > On 10/18/2012 12:13 PM, Alon Levy wrote:
> > >> On 10/16/2012 12:18 AM, David Jaša wrote:
> [snip]
> > >>> Extending spice to provide just serial console remoting
> > >>> actually
> > >>> seems
> > >>> the easiest way to provide remote text-only console because
> > >>> most of
> > >>> the
> > >>> code path is already mature (used for client to guest agent
> > >>> communication) and e.g. spicy to just provide a device where
> > >>> e.g.
> > >>> screen
> > >>> could connect or just provide the console itself.
> > >>>
> > >>> CCing spice-devel
> > >>
> > >> would it allow users to script with/over it like they can with
> > >> ssh?
> > >
> > > If I understand correctly the idea is to add another channel for
> > > spice that would connect to a char device in qemu that in turn
> > > connects to a serial port. The result is a spice client that can
> > > display and interact, but not a scripting extension. We could
> > > also create a unix domain socket to expose this connection on
> > > the client, and the client could then use that for scripting
> > > (but this will be instead of displaying, since you can't
> > > multiplex the console in a meaningful way - unless you run
> > > screen/tmux over it maybe):
> > >
> > > remote-viewer --spice-console-unix-domain-socket /tmp/spice.uds
> > > (This option assumes we want a single console channel - if we
> > > have multiple we will need to name them too)
> > >
> > > Anyone will be able to script it using for instance:
> > > socat UNIX-CONNECT:/tmp/spice.uds SYSTEM:"echo hello world"
> > >
> > > We could also turn it into a pty (socat can do that).
> > 
> > i think using spice this way may be a very good solution, to proxy
> > a
> > serial console.
> > only caveat is it requires client to install spice, vs. just using
> > ssh.
> 
> Jarda (To:) actually asked me if this feature (serial device pass
> through without any graphics) was feasible for purposes of connecting
> remotely to serial console.
> Jarda, would the solution outlined by Alon be good for you?
> 
> Alon, one problem comes to my mind though: it would need either
> second
> spice server, or multi-client support (limited one would be enough to
> have simultaneously one graphics user and one serial device user). Do
> you think it is possible to implement such things without much
> effort?

If we constrain it to one graphics only (no serial connection, i.e. same channels as today) and one serial only (i.e. main channel - since we have to have that, and the new serial console channel), I think it should not pose any of the problems keeping usable multiple client mode from being implemented, i.e. handling different speed clients.

> 
> David
> 
> --
> 
> David Jaša, RHCE
> 
> SPICE QE based in Brno
> GPG Key:     22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> 
> 
> 
> 
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]