qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 16/46] Add migration-capability boolean for post


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH 16/46] Add migration-capability boolean for postcopy-ram.
Date: Mon, 7 Jul 2014 22:23:27 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

* Eric Blake (address@hidden) wrote:
> On 07/04/2014 11:41 AM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > ---
> >  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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]