* Denis Plotnikov (dplotni...@virtuozzo.com) wrote: > > > On 13.02.2018 18:05, Dr. David Alan Gilbert wrote: > > * Denis V. Lunev (d...@virtuozzo.com) wrote: > > > On 02/13/2018 05:59 PM, Dr. David Alan Gilbert wrote: > > > > * Daniel P. Berrangé (berra...@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 / dgilb...@redhat.com / Manchester, UK > > > > -- > Best, > Denis -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK