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@xxxxxxxxxx>
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.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel