(1) libvirt sets spice ticket at dst (stage 2)
(2) migration src->dst (stage 3)
(3) spice client switches connection to dst
This is actually what we have already. The problem is that
the 'migration src->dst' here can take an arbitrary amount
of time. So by the time the spice client switchs to dst,
the ticket will likely have already expired.
Ah, *that* is the bug.
The only way to fix this AFAICT is to ensure the SPICE
client connects to dst before migration starts, but delays
display switch until the end. eg
(1) libvirt sets spice ticket at dst (libvirt stage 2)
(2) spice client connects to dst (start of libvirt stage 3)
That must be in stage 2. Once the migration started qemu will not
accept new connections and thus the client would not be able to connect.
Can qemu handle async monitor commands now? We would need to wait until
the client has actually connected, but without blocking the iothread
because it can take a while.
cheers,
Gerd
