From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StcDj-0003JD-Hp for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:20:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StcDd-000106-7y for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:20:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StcDc-000102-WC for qemu-devel@nongnu.org; Tue, 24 Jul 2012 06:19:57 -0400 Message-ID: <500E76C4.3060207@redhat.com> Date: Tue, 24 Jul 2012 12:19:48 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1343053380-12133-1-git-send-email-benoit@irqsave.net> <500E706E.8030405@redhat.com> In-Reply-To: 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: Stefan Hajnoczi Cc: pbonzini@redhat.com, benoit.canet@gmail.com, =?ISO-8859-1?Q?Beno=EE?= =?ISO-8859-1?Q?t_Canet?= , qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Am 24.07.2012 12:04, schrieb Stefan Hajnoczi: > 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 an= y of >>> 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. >=20 > 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. Sure, if you're migrating without shared storage, you always need to know what you're doing. But you could be doing a post-copy storage migration and migrate to the next host before it has completed. I think this is a completely legitimate action that shouldn't be blocked. Kevin