On 08/25/2011 01:53 PM, Gerd Hoffmann wrote:
I've played with a approach simliar to (2) long ago. Actually did it by registering a "live" migration handler. Didn't work that well too. spice client will stay connected to both source and target for a long time, and the spice code base simply couldn't handle that very well. One problem was a timeout somewhere which was *way* to short. Second was that some stuff such as new connects are blocked in that "migration" state. Doesn't hurt much if that lasts a second or two, but for a few minutes it isn't acceptable. Maybe there was more which I don't remember.
If we can't connect to the target during migration, this means the "not seamless" solution is problematic as well, and we may need ==> a libvirt change <== : We need to connect to the target before migration starts. We can either do it upon client_migrate_info, under the assumption that the target is already up and that it is called just before migration. Or otherwise, we need to introduce a new command from libvirt, just before migration, with the same assumptions.
Regarding the timeout: do you remember if it occured on the server display_channel? It is a timeout, but it shouldn't be triggered with the seamless migration path...
Yonit. _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
