Hi,
race 2: target starts before it manages to restore the source
pre-migration state (which was sent to it from the src server, via the
client).
solution:
the target won't attach any spice device interface till it restores its
state (with timeout). i.e., it will queue any request from the quest,
and will operate on them only after it has been restored.
From the vm_start code (vl.c), it looks like the start notifier is
called before the guest is actually started, so we can hold the target
from starting till we recover it. Gerd, is this correct?
Yes, the notifier is called first.
other changes in spice:
due to the broken seamless migration, spice channels were not maintained
to keep supporting it (i.e., sending the minimal amount of data that is
required for the target to restore the channel's state), especially the
new channels (smartcard, usb(?), agent transmissions, etc.). So,
implementation in this level is required as well.
Arnon, Alon, Hans, can you let me know how much work it would be to
support seemless migration for agent, smartcard, and usb (is it relevant
for rhel 6.3?)? Supporting seemless migration mainly requires (1)
sending SPICE_MSG_MIGRATE_DATA with data that will allow the target side
to be restored, so that the connection with the same client will stay
valid. (2) handle SPICE_MSGC_MIGRATE_DATA in the target
Do we have to support seamless migration for all channel types? Or is
it an option to support it for some channel types only to avoid
complexity if we don't need it?
I see the point in doing it for the display channel, all the surfaces in
the client cache will stay valid which will avoid alot of data being
resent to the client.
For the input channel it is alot less important. The agent should also
be able to just re-build the connection and be happy. Likewise the
smartcard. Not sure about sound, might be important because of mm_time
and a/v sync.
For USB it would certainly be nice to have, especially for stuff like
usb sticks where you want avoid the guest see a disconnect+reconnect for
a device which might have outstanding write requests. It is tricky
though as the data travels both ways (which is quite different from
display channel), so a simple SPICE_MSG_MIGRATE_DATA message might not
be enougth to handle seamless migration for usb.
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
