From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49655 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuM8w-0007LK-QZ for qemu-devel@nongnu.org; Tue, 01 Mar 2011 04:45:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuM8v-0001wy-A3 for qemu-devel@nongnu.org; Tue, 01 Mar 2011 04:45:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PuM8u-0001wg-T2 for qemu-devel@nongnu.org; Tue, 01 Mar 2011 04:45:21 -0500 Message-ID: <4D6CC02B.4070601@redhat.com> Date: Tue, 01 Mar 2011 11:45:15 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy References: <4D669C46.40909@codemonkey.ws> <4D6A150B.8030205@redhat.com> <4D6A58E0.9020607@codemonkey.ws> <4D6A6E38.4030700@redhat.com> <4D6A8CC9.4090304@codemonkey.ws> <4D6B5EFA.8060106@redhat.com> <4D6B98FD.7020103@codemonkey.ws> <4D6BA16A.2020204@redhat.com> <4D6BDFA1.3000100@redhat.com> <20110228185601.GB19740@amt.cnet> In-Reply-To: <20110228185601.GB19740@amt.cnet> 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: Marcelo Tosatti Cc: Jes.Sorensen@redhat.com, qemu-devel@nongnu.org On 02/28/2011 08:56 PM, Marcelo Tosatti wrote: > > > > Something that avoids the whole state thing altogether: > > > > - instead of atomically switching when live copy is done, keep on > > issuing writes to both the origin and the live copy > > - issue a notification to management > > - management receives the notification, and issues an atomic > > blockdev switch command > > How do you know if QEMU performed the switch or not? That is, > how can the switch command be atomic? If you fail while qemu processes the command, you query it to see what it's current state. You can simply re-issue the command; it's idempotent. If qemu fails before you issue the switch you discard the new copy. If it fails after the switch (whether it acked or not) you discard the original. > > this is really the RAID-1 solution but without the state file > > (credit Dor). An advantage is that there is no additional latency > > when trying to catch up to the dirty bitmap. > > So you're implementing a virtual block driver not visible to the user as > an image format. The image format would allow storage of persistent copy > progress, etc. so you lose all that. > > All of that to avoid introducing a commit file which is not part of > global qemu state. I think it has other advantages as well - code isolation, live migration compatibility, reduced switchover times. Really the bad thing about the commit file is its un-documented-ness and ad-hoc nature which means the management tool is unlikely to get things right. Qemu maintaining state is fine. It already does - in block devices, and should do more. We just have to take the right approach to do it (and be careful not to make it manage configuration). -- error compiling committee.c: too many arguments to function