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