From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0tt0-0003tU-0J for qemu-devel@nongnu.org; Mon, 23 Nov 2015 11:22:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0tsu-000098-SC for qemu-devel@nongnu.org; Mon, 23 Nov 2015 11:22:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0tsu-000092-Mc for qemu-devel@nongnu.org; Mon, 23 Nov 2015 11:22:32 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 763DBC0A8491 for ; Mon, 23 Nov 2015 16:22:31 +0000 (UTC) References: <1448273262-13845-1-git-send-email-peterx@redhat.com> From: Laszlo Ersek Message-ID: <56533D45.1060108@redhat.com> Date: Mon, 23 Nov 2015 17:22:29 +0100 MIME-Version: 1.0 In-Reply-To: <1448273262-13845-1-git-send-email-peterx@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH REPOST 0/2] Add basic "detach" support for dump-guest-memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu , qemu-devel@nongnu.org Cc: pbonzini@redhat.com, armbru@redhat.com, lcapitulino@redhat.com On 11/23/15 11:07, Peter Xu wrote: > Currently, dump-guest-memory supports synchronous operation only. This patch > sets are adding "detach" support for it (just like "migrate -d" for > migration). When "-d" is provided, dump-guest-memory command will return > immediately without hanging user. This should be useful when the backend > storage for the dump file is very slow. > > Peter Xu (2): > dump-guest-memory: add "detach" flag for QMP/HMP interfaces > dump-guest-memory: add basic "detach" support. > > dump.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++----- > hmp-commands.hx | 5 +++-- > hmp.c | 3 ++- > include/sysemu/dump.h | 4 ++++ > qapi-schema.json | 3 ++- > qmp-commands.hx | 4 ++-- > qmp.c | 9 ++++++++ > vl.c | 3 +++ > 8 files changed, 81 insertions(+), 12 deletions(-) > I'm not seeing anything that would prevent races between the new thread and any other existing threads that manipulate the MemoryRegion objects (in response to guest actions), or the guest RAM contents (by way of executing guest code). The dump_init() function has if (runstate_is_running()) { vm_stop(RUN_STATE_SAVE_VM); s->resume = true; } else { s->resume = false; } Whereas dump_cleanup() has: if (s->resume) { vm_start(); } If you return control to the QEMU monitor's user before the dump completes, they could issue the "cont" command, and unleash the VCPU threads again. (Of course, this is just one example where things could go wrong.) Also, the live migration analogy is not a good one IMO. For live migration, a whole infrastructure exists for tracking asynchronous guest state changes (dirty bitmap, locking, whatever). The good analogy with live migration would be continuous streaming of guest memory changes into the dump file, until it converges, or a cutoff is reached (at which point the guest would be frozen, same as now). Of course, such streaming could generate huge amounts of traffic and entirely defeat the original purpose. In total, I don't think this is a good idea. I find it possible that this would lead to QEMU crashes, and/or wildly inconsistent guest memory images. As for the goal itself... People also tend to cope with *kdump* being slow on physical machines. My recommendation would be to use the dump compression feature (especially lzo and snappy). In my experience, even when people are aware of their existence, they don't always realize that shrinking the dump file size by a given factor also shrinks the dumping *time* by the same factor, provided that the dumping process remains IO-bound even in the compressed case. Which it should, assuming a "very slow storage" -- lzo and snappy are very CPU-efficient. Thanks Laszlo