[Spice-devel] [RFC PATCH spice 0.8 01/19] server/spice.h: semi-seamless migration interface, RHBZ #738266

[Gerd Hoffmann]

On 09/19/11 11:46, Yonit Halperin wrote:
> semi-seamless migration details:
>
> migration source side
> ---------------------
> (1) spice_server_migrate_info (*): tell client to link
>      to the target side - send SPICE_MSG_MAIN_MIGRATE_BEGIN.
>      client_migrate_info cmd is asynchronous.
> (2) Complete client_migrate_info only when the client has been connected
>      to the target - wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) or a timeout.
> (3) spice_server_migrate_end: tell client migration it can switch to the target - send
>      SPICE_MSG_MAIN_MIGRATE_END.
> (4) client cleans up all data related to the connection to the source and switches to the target.
>      It sends SPICE_MSGC_MAIN_MIGRATE_END.

So the switch-host message will not be used any more?  How do you handle 
compatibility to spice servers which don't support this migration scheme?

This looks a bit like seamless migration half-done.  What is missing to 
full seamless migration support?  The spice channels need to transfer 
the state via client.  Also qemu on the source needs to wait for that to 
complete I guess?  Anything else?

>   enum {
>       SPICE_MIGRATE_CLIENT_NONE = 1,
>       SPICE_MIGRATE_CLIENT_WAITING,
>       SPICE_MIGRATE_CLIENT_READY,
>   };

Is that still needed?

> +/* migration interface */
> +#define SPICE_INTERFACE_MIGRATION "migration"
> +#define SPICE_INTERFACE_MIGRATION_MAJOR 1
> +#define SPICE_INTERFACE_MIGRATION_MINOR 1
> +typedef struct SpiceMigrateInterface SpiceMigrateInterface;
> +typedef struct SpiceMigrateInstance SpiceMigrateInstance;
> +typedef struct SpiceMigrateState SpiceMigrateState;
> +
> +struct SpiceMigrateInterface {
> +    SpiceBaseInterface base;
> +    void (*migrate_info_complete)(SpiceMigrateInstance *sin);
> +};
>
> +struct SpiceMigrateInstance {
> +    SpiceBaseInstance base;
> +    SpiceMigrateState *st;
> +};

Why a new interface?  The only purpose it seems to serve is adding a 
single callback.  It is registered unconditionally by the spice core 
code in qemu.  I fail to see why we can't just add the callback to the 
core interface.  That would save a bunch of code to handle the new 
interface.

I think we should try to make sure the qemu <-> spice-server migration 
API can handle both semi-seamless and real seamless client migration. 
Then the two spice servers can negotiate themself which method they 
pick, without qemu being involved here.  I think the minimum we'll need 
here is a second notification (when spice channel state migration via 
slient is finished), either using a second callback or by adding a 
reason argument to the one we have.  But maybe just blocking in 
spice_server_migrate_end() works too (the guest is stopped at that point 
anyway, so going async doesn't buy us that much here ...).

What is the plan for the master branch?  How will this work with 
multiclient enabled?

cheers,
   Gerd