On 7/31/2020 5:06 AM, Daniel P. Berrangé wrote: > On Thu, Jul 30, 2020 at 08:14:28AM -0700, Steve Sistare wrote: >> From: Mark Kanda <mark.ka...@oracle.com> >> >> Iterate through the VNC displays and save/restore the socket fds. > > This patch doesn't appear to do anything around the client state, so I > can't see how this will work in general. eg QEMU is 1/2 way through > receiving a message from the client, and we trigger re-exec. > > The new QEMU is going to startup considering the VNC client is in an > idle state, and will then read the 2nd 1/2 of the message off the > client socket. Everything will go rapidly downhill from there. > Or the reverse, the server has sent a message, but this outbound > message is still in the buffer and only been partially sent on the > wire. We re'exec and now we've lost the unsent part of the buffer.
Yes. For partial messages in qemu object buffers, we need to add a draining phase between exec-requested and exec, and complete all partial messages. For kernel socket buffers, we should be OK. If we are accurately preserving vnc server state (which is the intent), then we can correctly respond to any client reqwuests that were sent to us pre-exec but read into qemu post-exec. However, there is another icky issue with vnc. It only works reliably with raw encoding. Compressed streams accumulate state on the client side which ww cannot match on the server when we create a new zlib stream after exec. The vnc protocol defines a per-stream reset flag in the compression control word, which sounds like it should reset zlib state, but it does not for tigervnc. I have not tried other clients. vnc is one of the tricker patches in this series. It may be wisest to close the connection and require the client to reconnect. The virtual framebuffer is preserved, so the same content will be shown after reconnect. - Steve
