On 10/18/2012 12:13 PM, Alon Levy wrote:
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?
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.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel