[Spice-devel] changing the timing of spice client linking in migration (RHBZ #725009)

[Alon Levy]

On Thu, Aug 25, 2011 at 02:20:13PM +0300, Yonit Halperin wrote:
> On 08/25/2011 02:15 PM, Daniel P. Berrange wrote:
> >On Thu, Aug 25, 2011 at 02:13:01PM +0300, Yonit Halperin wrote:
> >>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.
> >
> >Yes, the target QEMU is neccessarily up by the time client_migrate_info
> >is run, because we need to know the SPICE port number for the running
> >target QEMU. We run client_migrate_info, immediately before running
> >migrate monitor command.
> >
> >If you're wanting to ensure the client connects to target QEMU before
> >migrate starts, then this implies that the libspice-server.so would
> >block in client_migrate_info, until it knows the client has succesfully
> >connected to the target ?
> >
> Yes, but with a reasonable timeout. But this is for seamless. And
> I'm not sure we want the seamless solution for 6.3

I thought it is for both seamless and the 'connect-on-migration-start' approach
you are suggesting here.

> 
> Thanks,
> Yonit.
> 
> >Daniel
>