[Spice-devel] [vdsm] [RFC]about the implement of text-based console

[Alon Levy]

> On 10/16/2012 12:18 AM, David Jaša wrote:
> > Ewoud Kohl van Wijngaarden píše v Po 15. 10. 2012 v 22:46 +0200:
> >> On Tue, Oct 16, 2012 at 12:51:23AM +0800, Xu He Jie wrote:
> >>> [SNIP]
> >>> Hi, Adam, Could you explain more detail about how streaming API
> >>> can
> >>> survive a VM migration?
> >>>
> >>> If we want to support migration, I think we should implement
> >>> console
> >>> server out of vdsm.
> >>> Actually, It will work like proxy. So we call it as consoleProxy
> >>> now. That consoleProxy can deploy on same machine with engine,
> >>> or standalone, or virtual machine. I think its' working flow as
> >>> below:
> >>>
> >>> 1. user request open console to engine.
> >>> 2. engine setTicket(uuid, ticket, hostofvm) to consoleProxy.
> >>>      consoleProxy need provide api to engine.
> >>> 3. engine return ticket to user.
> >>> 4. user 'ssh UUID at consoleProxy' with ticket.
> >>> 5. consoleProxy connect 'virsh -c qemu+tls://hostofvm/system
> >>> console'.
> >>>     the host of running consoleProxy should have certificates of
> >>>     all
> >>> vdsm host.
> >>> 6. consoleProxy redirect output of 'virsh -c
> >>> qemu+tls://hostofvm/system console' with ssh protocol.
> >>>     Same with currently implement. we can use system sshd or
> >>>     paramiko.
> >>>     If we use paramiko, it almost reuse the code of consoleServer
> >>> that I have already writen.
> >>>
> >>> After vm migrated:
> >>> 1. engine tell consoleProxy that vm was migrated.
> >>>      I guess engine can know vm finished migration?
> >>>      And engine how to push the event of vm finished migration to
> >>> consoleProxy? Engine only have rest api didn't support event
> >>> push?
> >>> Is streaming api can resolve this problem?
> >>> 2. consoleProxy kill 'virsh console'.
> >>> 3. reconnect to new host of vm with 'virsh console' again.
> >>>      There will missing some character if the reconnection isn't
> >>> enough fast.
> >>>      This is hardly to resolve except implement ssh in qemu. I
> >>>      guess
> >>> streaming api have some problem too.
> >>> 4. continue redirect 'virsh console'.
> >>>
> >>> Actually if we implement consoleProxy out of vdsm, we don't need
> >>> decide it will run on physical machine or
> >>> virtual machine now.
> >>>
> >>> A lot detail need to think. I'm not cover all problem. And I
> >>> haven't
> >>> code to prove that work now. Just depend on thinking.
> >>>
> >>> Is this make sense?
> >>
> >> How is this handled with current displays like VNC and Spice?
> >
> > 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).

> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>