On 09/19/2011 07:13 PM, Gerd Hoffmann wrote:
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().
(A) Is it possible to hold the target paused (but not blocked) after the
non-live stage completes? If it is possible (6) is not necessary as long
as spice_server_migrate_end will be called before the target vm is started.
Qemu on the target:
(1) receive migration
(2) wait for spice-server to complete client migration
[ need api for that ]
(B) If the answer for (A) is yes, maybe this should be done through the
client and the src server:
(1) target spice-server completes client migration, acks the client,
(2) the client disconnects from the src or sends an appropriate message
to the src server
(3) src server completes spice_server_migrate_end (async?), and make the
target vm start.
If the answer for (A) is no, then spice will need qemu to have a
migration completion async notifier in the target side as well.
(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?
Yes
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
