From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrvC5-0001JK-8B for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:39:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrvBz-0002r5-AJ for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:39:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrvBz-0002r1-3K for qemu-devel@nongnu.org; Mon, 30 Jan 2012 12:38:59 -0500 Message-ID: <4F26D5AB.9040801@redhat.com> Date: Mon, 30 Jan 2012 10:38:51 -0700 From: Eric Blake MIME-Version: 1.0 References: <4F1784EE.2040800@cn.fujitsu.com> <4F17907E.4070302@cn.fujitsu.com> <4F184607.10509@redhat.com> <4F262D44.9040109@cn.fujitsu.com> In-Reply-To: <4F262D44.9040109@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5240F13F283AD08B90ECA4D2" Subject: Re: [Qemu-devel] [RFC][PATCH 00/15 v5] introducing a new, dedicated memory dump mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Jan Kiszka , qemu-devel , Luiz Capitulino , HATAYAMA Daisuke , Dave Anderson , Jun Koi This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5240F13F283AD08B90ECA4D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/29/2012 10:40 PM, Wen Congyang wrote: >>> Yes, it may tak a lot of time. But we dump a guest memory when the gu= est >>> panics, and there is no need to continue to run the guest. >> >> Would it be possible to have both a dump from a certain point in time >> and still allow the guest to run unpaused? >> >> I'm thinking something along the lines of pausing the guest, setting u= p >> control structures, then calling fork(). The parent can then unpause,= >> and use the control structures to communicate the memory state from th= e >> child back out the monitor. Meanwhile, the guest has a copy-on-write >> clone of the entire memory state, so as long as the control structures= >> guarantee that the child will not accept any monitor commands and not >> resume the guest, then the child process can be used to stream the >> memory contents as they were at the time of the dump command back over= >> the control structure back to the parent process. I will admit, >> however, that following the fork(), you would be limited to >> async-signal-safe functions, so it may be a rather difficult task to d= esign. >> >=20 > I do not understand this section. Do you say the reason of allowing the= guest > to run unpaused? Or do you say the way to do it? Among other reasons for supporting a guest that runs in parallel with a memory dump, I'm envisioning a thin-provisioning setup. Right now, you have to get a common off-line base disk image state, then each cloned guest has to boot from scratch as a delta from that base state. But it would be a lot faster if you could get a common on-line VM state, and start cloned guests from the same memory state as the baseline. Taking it further, I can envision a forensic-style application, that runs what-if scenarios, by running two similar guests side by side and seeing what happens when only one of the two guests has a particular tweak made. Or suppose you have a production server, and want to apply a patch, but want to make sure the patch will work before committing to it - the obvious way is to apply the patch to a temporary cloned VM. But because it is a production server, you can't afford to wait for a long downtime with the guest paused just to capture the machine state for cloning a temporary VM for testing out the patch. Basically, in all of these scenarios, my idea is that it should be easy (well, at least easier than it currently is), to create a new guest based on the memory state of an existing guest, all without impacting the existing guest. And to do that, it would be nice to be able to reliably dump the state of memory of a guest at a given point of time, all while continuing to let the original guest run past that point in tim= e. But whether this has to be done right away, or whether it even fits in with your 'dump' command vs. needing a command of its own, I don't know. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig5240F13F283AD08B90ECA4D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPJtWrAAoJEKeha0olJ0Nq8joIAKRAYDDzdOZ5XzGlCYwQXlfz bs0u5q2cf+JIKObioBpp7t+h1wx3YQFqij1EqwJl20WZDlR9L45sEljSLyEmHiXF WQB4TdIZDPorsPkNdzzyDICyopq1S4nrjkf1gHXTNqcoXD+tsHri6r6NLl3ZbhG2 MWr2kjCzCErYPW3bjBidlYG4f3iAgUPdAU/AEeUb/DEro53u3uMqmiZ00JXxwc4h 7BDRUZpox4VGpnh7c758wZn/eXCFaGG6zGFA+iZOzL1BHkbpUt02h3mocwSTPSqY qZqImqGlGSiw2uA5s1HVlke5V5gzve5p7Qfh0xEBe+J/TgjPpuk9QIJYq8gJnBg= =0RoO -----END PGP SIGNATURE----- --------------enig5240F13F283AD08B90ECA4D2--