On 09/13/2012 11:06 AM, Michal Privoznik wrote:
> Recently, there have been some improvements made to qemu so it
> supports seamless migration or something very close to it.
> However, it requires libvirt interaction. Once qemu is migrated,
> the SPICE server needs to send its internal state to the destination.
> Once it's done, it fires SPICE_MIGRATE_COMPLETED event and this
> fact is advertised in 'query-spice' output as well.
> We must not kill qemu until SPICE server finishes the transfer.
> ---
>
> Okay, I am ignoring the event completely in this patch.
> I am just asking for 'query-spice' until after 'query-migrate'
> reports 'completed'. It's simple and small.
> However, if there is a wider consensus I should catch the
> event as well, e.g. so we don't have to enter the monitor
> and thus have smaller overhead, I can rewrite this patch.
I think this approach is incomplete. As I understand it from the qemu
side of things, qemu commit 8c95705:
The seamless-migration flag is required in order to identify
whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
(by default the flag is off).
New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED
should turn on this flag.
When this flag is off, spice fallbacks to its old migration method,
which
can result in data loss.
That is, only new qemu supports seamless migration, but it only does so
if both the sending side has been notified to send the event, and the
receiving side has been told to receive in seamless mode; both sides
have to be in the same mode. Therefore, I think you are missing a
change to qemu_capabilities.[hc] to probe whether the qemu instance
supports the new spice migration abilities (check on the source, because
it must be enabled at the time qemu is started, which also impacts
qemu_command.c; and check on the destination, since we must fail
migration if the destination does not support the same mode as the host).
Hmm, in just writing that, I wonder if we need even more - if we KNOW
that we will want to migrate to a destination that does not support
seamless migration, then we want to disable the seamless-migration
option on the source at the time we start the VM; sounds like we need to
enhance our XML for <graphics> to allow the user to control whether
seamless migration is mandatory (source and dest must be new qemu),
forbidden (can mix old and new qemu on either end), or defaults to the
abilities of the source (if source is new, dest must be new; but source
can be old).
As to your question about whethe libvirt should wait for the new event:
waiting is nicer than polling, but since events can be missed, your
approach of polling query-spice seems decent enough (I'm not quite sure
how this interacts with restarting libvirtd while a migration is in
progress, but polling a monitor command can be resumed when libvirtd
restarts, while a missed event will never be seen again).
I haven't looked at the code itself, because I'm worried we need the XML
design added first, which turns this into a patch series.
--
Eric Blake eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list