Hi,
We need to handle another case: New client. New source server. Old
target server.
Indeed.
2. When client connects to the server it sees that the server doesn't
have the SEMI_SEAMLESS_CAP present. So it disconnects, and sends to
the source a
SPICEC_MSG_MIGRATE_TARGET_CONNECTION_FAILED_TARGET_TOO_OLD , or maybe
just a generic error message (if we have something like that) and use
that as the reason. The server sees this, and proceeds to do the old
switch host behavior.
Sounds good to me.
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?
We are still missing keeping the target stopped till the target
spice server is restored from the data passed through the client.
Thanks to the fix Alon sent for RHBZ #729621, we could block the
target from starting using a vm state change handler, but it is a
workaround... IMHO, if we could have async notifiers for migration
before it starts and just before it completes (as we had in Rhel5),
that would have been the best solution (it will also allow us not
to use client_migrate_info for the pre-connection to the target).
For now I'll try to see the big picture (aka API needed), not the little
implementation details. Whenever we kick off the migration from the
client_info or the migration notifier doesn't matter for the
libspice-server API, that is an detail which can easily be changed once
we have the notifiers in place.
The steps needed for seamless migration, qemu on the source:
(1) spice_server_migrate_info()
(2) spice_server_migrate_start()
(3) wait for the callback, async needed as the vm is running.
(4) do migration, live stage.
(5) stop virtual machine (and qxl worker).
(6) Guess we need to notify spice-server here?
Maybe call spice_server_migrate_start() here and rename the
call in (2) to spice_server_migrate_connect() ?
(7) do migration, non-live stage.
(8) spice_server_migrate_end().
Qemu on the target:
(1) receive migration
(2) wait for spice-server to complete client migration
[ need api for that ]
(3) start virtual machine (and qxl worker).
Correct?
semi-seamless should work with that workflow too, even though
spice-server probably hasn't anything to do at source step (6) and
target step (2), correct?
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
