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

[David Jaša]

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

David

> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24