Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Denis Plotnikov (dplotnikov@virtuozzo.com) wrote:
> 
> 
> On 13.02.2018 18:05, Dr. David Alan Gilbert wrote:
> > * Denis V. Lunev (den@virtuozzo.com) wrote:
> > > On 02/13/2018 05:59 PM, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > > > > On Tue, Feb 13, 2018 at 03:45:21PM +0100, Kevin Wolf wrote:
> > > > > > Am 13.02.2018 um 15:36 hat Daniel P. Berrangé geschrieben:
> > > > > > > On Tue, Feb 13, 2018 at 05:30:02PM +0300, Roman Kagan wrote:
> > > > > > > > On Tue, Feb 13, 2018 at 11:50:24AM +0100, Kevin Wolf wrote:
> > > > > > > > > Am 11.01.2018 um 14:04 hat Daniel P. Berrange geschrieben:
> > > > > > > > > > Then you could just use the regular migrate QMP commands for loading
> > > > > > > > > > and saving snapshots.
> > > > > > > > > Yes, you could. I think for a proper implementation you would want to do
> > > > > > > > > better, though. Live migration provides just a stream, but that's not
> > > > > > > > > really well suited for snapshots. When a RAM page is dirtied, you just
> > > > > > > > > want to overwrite the old version of it in a snapshot [...]
> > > > > > > > This means the point in time where the guest state is snapshotted is not
> > > > > > > > when the command is issued, but any unpredictable amount of time later.
> > > > > > > > 
> > > > > > > > I'm not sure this is what a user expects.
> > > > > > > > 
> > > > > > > > A better approach for the save part appears to be to stop the vcpus,
> > > > > > > > dump the device state, resume the vcpus, and save the memory contents in
> > > > > > > > the background, prioritizing the old copies of the pages that change.
> > > > > > > > No multiple copies of the same page would have to be saved so the stream
> > > > > > > > format would be fine.  For the load part the usual inmigrate should
> > > > > > > > work.
> > > > > > > No, that's policy decision that doesn't matter from QMP pov. If the mgmt
> > > > > > > app wants the snapshot to be wrt to the initial time, it can simply
> > > > > > > invoke the "stop" QMP command before doing the live migration and
> > > > > > > "cont" afterwards.
> > > > > > That would be non-live. I think Roman means a live snapshot that saves
> > > > > > the state at the beginning of the operation. Basically the difference
> > > > > > between blockdev-backup (state at the beginning) and blockdev-mirror
> > > > > > (state at the end), except for a whole VM.
> > > > > That doesn't seem practical unless you can instantaneously write out
> > > > > the entire guest RAM to disk without blocking, or can somehow snapshot
> > > > > the RAM so you can write out a consistent view of the original RAM,
> > > > > while the guest continues to dirty RAM pages.
> > > > People have suggested doing something like that with userfault write
> > > > mode; but the same would also be doable just by write protecting the
> > > > whole of RAM and then following the faults.
> > > 
> > > nope, userfault fd does not help :( We have tried, the functionality is not
> > > enough. Better to have small extension to KVM to protect all memory
> > > and notify QEMU with accessed address.
> > 
> > Can you explain why? I thought the write-protect mode of userfaultfd was
> > supposed to be able to do that; cc'ing in Andrea
> 
> Hi everybody
> 
> Yes, that's true but it isn't implemented yet in the kernel
> 
> ...
> userfaultfd_register
> 
>         if (uffdio_register.mode & UFFDIO_REGISTER_MODE_WP) {
>                 vm_flags |= VM_UFFD_WP;
>                 /*
>                  * FIXME: remove the below error constraint by
>                  * implementing the wprotect tracking mode.
>                  */
>                 ret = -EINVAL;
>                 goto out;
>         }
> 
> and I don't feel like doing that taking into account that somebody has it
> done already
> but when it's done I'll use it with pleasure.
> 
> KVM need to tiny wini modification to be made in its mmu part which would
> tell to the userspace the fault address. This is a simple solution which can
> be used while we're living without userfaultfd.

OK, but lets just have one last check with Andrea to see the state of
it; if it's almost ready to go then lets just try and push it over the
line.

Dave

> > 
> > Dave
> > 
> > > Den
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
> 
> -- 
> Best,
> Denis
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK