From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4c9D-0005Ax-Ka for qemu-devel@nongnu.org; Wed, 21 Apr 2010 11:47:31 -0400 Received: from [140.186.70.92] (port=35607 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4c97-000559-HK for qemu-devel@nongnu.org; Wed, 21 Apr 2010 11:47:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4c93-0004Kk-3u for qemu-devel@nongnu.org; Wed, 21 Apr 2010 11:47:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18163) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4c91-0004KI-Qk for qemu-devel@nongnu.org; Wed, 21 Apr 2010 11:47:21 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3LFlIMO013771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 Apr 2010 11:47:19 -0400 From: Juan Quintela In-Reply-To: <4BCF1948.6090600@redhat.com> (Kevin Wolf's message of "Wed, 21 Apr 2010 17:27:04 +0200") References: <1271797792-24571-1-git-send-email-lcapitulino@redhat.com> <1271797792-24571-5-git-send-email-lcapitulino@redhat.com> <4BCEFD70.70100@redhat.com> <20100421120838.4aa8428c@redhat.com> <4BCF1948.6090600@redhat.com> Date: Wed, 21 Apr 2010 17:47:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH 04/22] savevm: do_loadvm(): Always resume the VM List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: armbru@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Kevin Wolf wrote: > Am 21.04.2010 17:08, schrieb Luiz Capitulino: > A different status that disallows cont sounds good. But exit() would > work for me as well and is probably easier. However, I'm not sure if it > would work well for management. I think that management would prefer it. It is developers who try to loadvm several times on the same machine. For management, if loadvm fails, having to restart qemu is the less of its problems, they already have infrastructure to kill process and rerun (probably with something tweeaked). >> Defining the right behavior and deciding what to expose have been >> proven very difficult tasks in the QMP world. > > There's nothing QMP specific about it. The problem has always been > there, QMP just means that you involuntarily get to review all of it. And we are thankful for the review :) Later, Juan.