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

[Yonit Halperin]

On 08/26/2011 10:56 AM, Alon Levy wrote:
> 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.
You are right. Even on the not seamless solution we need to make sure 
the client is connected before migration starts, since after it starts, 
the target can't accept connections.
(Sorry for the late response, forgot to reply).
>
>>
>> Thanks,
>> Yonit.
>>
>>> Daniel
>>