From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StbyT-0008SO-GE for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:04:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StbyK-0004kr-2j for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:04:17 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:46167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StbyJ-0004kk-Rw for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:04:07 -0400 Received: by bkcji1 with SMTP id ji1so5185421bkc.4 for ; Tue, 24 Jul 2012 03:04:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <500E706E.8030405@redhat.com> References: <1343053380-12133-1-git-send-email-benoit@irqsave.net> <500E706E.8030405@redhat.com> Date: Tue, 24 Jul 2012 11:04:07 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: pbonzini@redhat.com, benoit.canet@gmail.com, =?ISO-8859-1?Q?Beno=EEt_Canet?= , qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com On Tue, Jul 24, 2012 at 10:52 AM, Kevin Wolf wrote: > Am 23.07.2012 16:22, schrieb benoit.canet@gmail.com: >> From: Beno=EEt Canet >> >> This patchset is designed to avoid starting a live migration while any o= f >> the block device is busy. >> >> Tested with the following sequence: >> >> QEMU 1.1.50 monitor - type 'help' for more information >> (qemu) block_stream virtio0 1k >> (qemu) migrate tcp:localhost:4444 >> migrate: Migration is blocked by streaming >> (qemu) block_job_cancel virtio0 >> (qemu) migrate tcp:localhost:4444 >> migrate: Connection can not be completed immediately >> (qemu) >> =3D> migration then succeed > > Maybe I'm missing the obvious, but why? Migration will stop the > streaming if it isn't restarted explicitly on the destination, but I > think that's expected. Hmm...maybe this is a policy decision. I figure if you are running image streaming and try to migrate, chances are you're migration will break on the destination host because you were trying to do pre-copy storage migration and never finished. Stefan