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@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?
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel