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

[Itamar Heim]

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?