From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eldib-0001pQ-7H for qemu-devel@nongnu.org; Tue, 13 Feb 2018 11:46:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eldia-0001C4-Dr for qemu-devel@nongnu.org; Tue, 13 Feb 2018 11:46:09 -0500 References: <20180107122336.29333-1-richiejp@f-m.fm> <5cf19623-72ac-fb8b-2054-a60d42419ec6@redhat.com> <20180111130427.GG8326@redhat.com> <20180213105024.GC5083@localhost.localdomain> <20180213143001.GA2354@rkaganb.sw.ru> <20180213143615.GN573@redhat.com> <20180213144521.GI5083@localhost.localdomain> <20180213144838.GO573@redhat.com> From: Eric Blake Message-ID: <1ac12a06-4031-f35c-da18-8c1cbbf7921d@redhat.com> Date: Tue, 13 Feb 2018 10:46:00 -0600 MIME-Version: 1.0 In-Reply-To: <20180213144838.GO573@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] Add save-snapshot, load-snapshot and delete-snapshot to QAPI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "=?UTF-8?Q?Daniel_P._Berrang=c3=a9?=" , Kevin Wolf Cc: Richard Palethorpe , Denis Lunev , Qemu-block , quintela@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, Denis Plotnikov , Roman Kagan , Max Reitz , rpalethorpe@suse.com, dgilbert@redhat.com On 02/13/2018 08:48 AM, Daniel P. Berrang=C3=A9 wrote: >>> No, that's policy decision that doesn't matter from QMP pov. If the m= gmt >>> 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. >=20 > 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=20 continues processing the guest, while the child writes out RAM pages.=20 Pages touched by the guest in the parent are now cleanly copied by the=20 OS so that the child can take all the time it wants, but still writes=20 out the state of the guest at the time of the fork(). It may be=20 possible to use userfaultfd to achieve the same effects without a fork(). --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org