On 02/13/2018 07:46 PM, Eric Blake wrote: > On 02/13/2018 08:48 AM, Daniel P. Berrangé wrote: >>>> 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. > > One idea for that is via fork()'s copy-on-write semantics; the parent > continues processing the guest, while the child writes out RAM pages. > Pages touched by the guest in the parent are now cleanly copied by the > OS so that the child can take all the time it wants, but still writes > out the state of the guest at the time of the fork(). It may be > possible to use userfaultfd to achieve the same effects without a fork(). > this would be problematic as we for sure will face memory problems. Guest stalls are IMHO much less problematic (as they are expected by end-user) then memory shortage.
Anyway, this is discussable. Den