From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWUNw-0005aP-MY for qemu-devel@nongnu.org; Mon, 21 May 2012 11:19:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWUNo-0001Mf-Em for qemu-devel@nongnu.org; Mon, 21 May 2012 11:19:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWUNo-0001ML-6Y for qemu-devel@nongnu.org; Mon, 21 May 2012 11:18:52 -0400 Message-ID: <4FBA5CD5.9090103@redhat.com> Date: Mon, 21 May 2012 17:18:45 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4FB6821A.1080902@redhat.com> <4FBA0AF9.8080705@redhat.com> <4FBA129E.80802@redhat.com> <4FBA19D7.1000806@redhat.com> <4FBA20D6.10507@redhat.com> <4FBA3E19.5020901@redhat.com> In-Reply-To: <4FBA3E19.5020901@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Proposal for extensions of block job commands in QEMU 1.2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Federico Simoncelli , Luiz Capitulino , Eric Blake , qemu-devel , Stefan Hajnoczi Il 21/05/2012 15:07, Kevin Wolf ha scritto: > Am 21.05.2012 13:02, schrieb Paolo Bonzini: >> Il 21/05/2012 12:32, Kevin Wolf ha scritto: >>> Am 21.05.2012 12:02, schrieb Paolo Bonzini: >>>> Il 21/05/2012 11:29, Kevin Wolf ha scritto: >>> If source/target is really the distinction we want to have, should the >>> available options be specific to the job type, so that you could have >>> src_error and dst_error for mirroring? >> >> Yes, that would make sense. > > Of course, at the same time it also makes the implementation a bit more > complicated. Not much, I'd have rerror/werror already split if I followed my spec. >>> Management doesn't necessarily exist. >> >> Even a human sitting at a console is management. (Though I don't plan >> HMP to expose rerror/werror; so you can assume in some sense that >> management exists). > > But it's management that cares about good defaults. :-) > > Why not expose the options in HMP? Honestly, because it's a pain. HMP doesn't have options with arguments, and I don't really care if HMP users curse at me because they end out-of-disk-space and their migration is dropped. If you're using HMP, more than likely: 1) you can just stop the VM and copy the storage manually; 2) even if you can't, if you get an EIO you can just stop the VM and figure the root cause. As far as storage migration is concerned (and quite a few other scenarios) HMP is a nice debugging tool, nothing more. >>>> Management may want to keep the VM stopped even for an error on the >>>> target, as long as mirroring has finished the initial synchronization >>>> step. The VM can perform large amounts of I/O while the job is paused, >>>> and then completing the job can take a large amount of time. >>> >>> If management wants to limit the impact of this, it can decide to >>> explicitly stop the VM when it receives the error event. >> >> That can be too late. >> >> Eric, is it a problem for libvirt if a pause or target error during >> mirroring causes the job to exit steady state? That means that after a >> target error the offset can go back from 100% to <100%. > > "too late" in what respect? Too late to properly show the error... though actually there is no guarantee that the VM will not clobber the error even with vm_stop, so it doesn't make a big difference in that, too. >> So for now I'll keep my proposed extension of query-block-jobs; later it >> can be modified so that the target will have a name if you started the >> mirroring with blockdev_mirror instead of drive_mirror. > > You mean the same QMP field is a string when the block device was added > with blockdev_add and a dict when it was added with drive_add? > Maintaining this sounds like a nightmare to me. No, the same QMP field is a dict. With blockdev_add it will have a name, and it will just be a shortcut to info block/info blockstat. With drive_add it will have no name. Paolo