Hi,
Ok, so I think we should be able to fix the race outlined above
without adding new monitor commands, just by letting libvirt set the
spice ticket in stage 2.
Is that different then what I suggested in my reply to Daniel's 5 stage outline?
I think we have to care to not mix up switch-host and seamless spice
client migration, your reply seems to refer top some seamless spice
migration implementation ideas.
Today we seem to have this workflow:
(1) migration src->dst (stage 3)
(2a) libvirt sets spice ticket at dst (not sure which stage)
(2b) spice client switches connection to dst
2a and 2b are racing here. I think we can fix the race by doing this
instead:
(1) libvirt sets spice ticket at dst (stage 2)
(2) migration src->dst (stage 3)
(3) spice client switches connection to dst
cheers,
Gerd
