From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57263 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsE7E-0006Ae-8Q for qemu-devel@nongnu.org; Wed, 23 Feb 2011 07:46:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsE7D-00006H-3j for qemu-devel@nongnu.org; Wed, 23 Feb 2011 07:46:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsE7C-00005r-Ij for qemu-devel@nongnu.org; Wed, 23 Feb 2011 07:46:47 -0500 Message-ID: <4D6501B0.2060309@redhat.com> Date: Wed, 23 Feb 2011 14:46:40 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy References: <20110222170004.808373778@redhat.com> <20110222170115.710717278@redhat.com> <4D642181.4080509@codemonkey.ws> <20110222210735.GA9372@amt.cnet> <4D64266A.3060106@codemonkey.ws> In-Reply-To: <4D64266A.3060106@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jes.Sorensen@redhat.com, Marcelo Tosatti , qemu-devel@nongnu.org On 02/22/2011 11:11 PM, Anthony Liguori wrote: >> The commit file is considered reliable storage for the result of image >> switch operation. Think of the following scenario: >> >> - mgmt app requests live copy of guests ide1-hd0 >> from /a/image.img to /b/image.img. >> - mgmt app dies. >> - guest switches to /b/image.img, /a/image.img is outdated. >> - guest dies. >> >> Notifying the switch via QMP would not be reliable in this case. > > But this is true of any number of operations in QEMU such as hotplug > where if a management tool dies after requesting hotplug and then the > guest dies before the management tool reconnects, it's never known > whether it's truly connected or not. > > The only way to robustly solve this is for QEMU to maintain a stateful > config file. Or, the management tool can remember that it tries to hotplug, reconnect, query qemu (or just retry), and proceed according to the result: - insert record in config for the new device, status = inactive - commit - tell qemu to hotplug - restart, read database, see inactive device - query qemu - if device is there, mark as active, commit - else, tell qemu to hotplug, when successful, mark as active, commit > A one-off for this particular command doesn't seem wise to me. Strongly agreed. -- error compiling committee.c: too many arguments to function