* Eric Blake (ebl...@redhat.com) wrote:
> On 07/04/2014 11:41 AM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> >
> > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> > ---
> > include/migration/migration.h | 1 +
> > migration.c | 9 +++++++++
> > qapi-schema.json | 6 +++++-
> > 3 files changed, 15 insertions(+), 1 deletion(-)
> >
>
> > +++ b/qapi-schema.json
> > @@ -491,10 +491,14 @@
> > # @auto-converge: If enabled, QEMU will automatically throttle down the
> > guest
> > # to speed up convergence of RAM migration. (since 1.6)
> > #
> > +# @x-postcopy-ram: Start executing on the migration target before all of
> > RAM has been
> > +# migrated, pulling the remaining pages along as needed. NOTE: If
> > the
> > +# migration fails during postcopy the VM will fail. (since 2.2)
>
> How does this work with libvirt's current insistence that it manually
> resumes the guest on the destination in order to give feedback to the
> source on whether it was successful? I'm not sure if enabling this bool
> is the right thing to do, or if we just need more visibility (such as
> events rather than the current state of polling) for libvirt to know
> that it is time to resume the destination and start the post-copy phase.
That's an interesting overlap with Paolo's question.
(and approximately the same answer)
I think what I need to do for that is:
1) As for precopy add the option not to start the destination CPU on entry
to postcopy;
I think that's OK, because we can carry on in postcopy mode even if the
destination
CPU isn't running, we just won't generate page requests.
2) Finally fix up the old request libvirt has for events based on migration
state.
Admittedly I don't quite understand how (1) is supposed to interact with device
state.
Dave
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
