[Spice-devel] [PATCH 5/7] Don't increment num_clients_mig_wait twice

Uri Lublin uril at redhat.com
Thu Oct 13 09:47:53 UTC 2016


On 10/12/2016 05:19 PM, Pavel Grunt wrote:
> On Wed, 2016-10-12 at 10:13 -0400, Frediano Ziglio wrote:
>>>
>>> On Wed, 2016-10-12 at 06:57 -0400, Frediano Ziglio wrote:
>>>>>
>>>>>
>>>>> When MainChannelClient was split to a separate file, the
>>>>> responsibility
>>>>> for incrementing this field was supposed to belong to the
>>>>> MainChannel
>>>>> function (main_channel_connect_semi_seamless()), but by
>>>>> mistake it
>>>>> was
>>>>> incremented both there and in the client function
>>>>> (main_channel_client_connect_semi_seamless()).
>>>>>
>>>>> The bug was introduced in
>>>>> a11b785f191d2381932f8c1bb6281539f2afe483
>>>>> ---
>>>>>  server/main-channel-client.c | 2 --
>>>>>  1 file changed, 2 deletions(-)
>>>>>
>>>>> diff --git a/server/main-channel-client.c b/server/main-
>>>>> channel-
>>>>> client.c
>>>>> index b30083f..0913028 100644
>>>>> --- a/server/main-channel-client.c
>>>>> +++ b/server/main-channel-client.c
>>>>> @@ -704,7 +704,6 @@ void
>>>>> main_channel_client_migrate(RedChannelClient *rcc)
>>>>>  gboolean
>>>>> main_channel_client_connect_semi_seamless(MainChannelClient
>>>>> *mcc)
>>>>>  {
>>>>>      RedChannelClient *rcc = RED_CHANNEL_CLIENT(mcc);
>>>>> -    MainChannel* main_channel =
>>>>> MAIN_CHANNEL(red_channel_client_get_channel(rcc));
>>>>>      if (red_channel_client_test_remote_cap(rcc,
>>>>>                                             SPICE_MAIN_CAP_SEM
>>>>> I_SEA
>>>>> MLESS_MIGRATE))
>>>>>                                             {
>>>>>          RedClient *client =
>>>>> red_channel_client_get_client(rcc);
>>>>> @@ -718,7 +717,6 @@ gboolean
>>>>> main_channel_client_connect_semi_seamless(MainChannelClient
>>>>> *mcc)
>>>>>              mcc->priv->mig_wait_connect = TRUE;
>>>>>          }
>>>>>          mcc->priv->mig_connect_ok = FALSE;
>>>>> -        main_channel->num_clients_mig_wait++;
>>>>>          return TRUE;
>>>>>      }
>>>>>      return FALSE;
>>>>
>>>> Acked-by: Frediano Ziglio <fziglio at redhat.com>
>>>>
>>>> I think we have a lack of testing, at least fast ones.
>>>
>>> Yes, definitely.
>>>
>>>> How did you discover this?
>>>
>>> Just code inspection. While splitting out the MainChannelPrivate
>>> stuff
>>> into a separate patch, I noticed that this hunk was included in
>>> the
>>> "Convert RedChannel Hierarchy to GObject" patch. And it looked odd
>>> to
>>> me, so I went to look at the history of this particular code.
>>>
>>>> Did you manage to reproduce the issue?
>>>
>>> No.
>>>
>>
>> I remember Uri can test migration locally but I never dig around
>> enough.
>> Uri, how to test it locally?
>
> Take a look at:
> https://cgit.freedesktop.org/spice/spice/tree/tests/migrate.py

That's a good test.
Seems like an n'th version of a test I wrote long ago :-)

Would be nice to add seamless migration support.

Frediano, to do it manually I basically run the same qemu-kvm
command in two terminals, one is the migration source and
the other migration destination. On a third terminal I run the client.
You have to give them different spice-port and destination
has to have incoming tcp:localhost:$migration-port
For each src/dst I add "monitor=stdio" such that it accepts
commands from stdin.
For seamless migration you want to add ",seamless-migration=on" to the 
command line and issue qemu monitor command on the src:
(qemu-src) client_migrate_info spice localhost $remote-spice-port

You can verify the client is connected to dst with (not needed)
(qemu-dst) info spice

and than migrate
(qemu-src) migrate [-d (*)] tcp:localhost:$migration-port

you can make it go faster/slower (*) with
(qemu-src) migrate_set_speed

and query the status (*) with
(qemu-src) info migrate

(*) You can issue those commands during migration if
     you ran migrate with "-d"

Upon successful completion quit the src as dst is now
the active instance of the VM.
(qemu-src) quit


Uri.



More information about the Spice-devel mailing list