From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi4tU-0008Mq-Om for qemu-devel@nongnu.org; Fri, 02 Oct 2015 14:17:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zi4tT-0001SC-Q4 for qemu-devel@nongnu.org; Fri, 02 Oct 2015 14:17:20 -0400 References: <1443717273-5280-1-git-send-email-jsnow@redhat.com> <1443717273-5280-2-git-send-email-jsnow@redhat.com> <560D758E.7020309@redhat.com> From: John Snow Message-ID: <560ECA27.2050805@redhat.com> Date: Fri, 2 Oct 2015 14:17:11 -0400 MIME-Version: 1.0 In-Reply-To: <560D758E.7020309@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/3] block: prohibit migration during BlockJobs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-block@nongnu.org Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On 10/01/2015 02:03 PM, Paolo Bonzini wrote: > > > On 01/10/2015 18:34, John Snow wrote: >> Unless we can prove this to be safe for specific cases, >> the default should be to prohibit migration during BlockJobs. > > Block jobs do not affect the current block, only other block device, > hence they *are* safe for migration. > Can you elaborate for me here? > What you want, I think, is the target not to be garbage when migration > ends. Based on this you can block specific cases, namely mirror which > you already do allow (patch 2) and backup except for sync='none'. > > Paolo > It would be nice if the target wasn't garbage, yes :) I allow mirror in specific circumstances -- you can't start a mirror, but if an existing mirror has hit the sync phase, that's OK. I can try to do a more exhaustive audit of what should and should not work, but my thought was "guilty before proven innocent." >> In conjunction with >> "migration: disallow_migrate_add_blocker during migration", >> this should be sufficient to disallow the blockjob from starting >> in the event of an in-progress migration. >