From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A23C0C352AA for ; Wed, 2 Oct 2019 07:35:46 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 78F2B206BB for ; Wed, 2 Oct 2019 07:35:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 78F2B206BB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:52300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFZAn-0007Id-Mw for qemu-devel@archiver.kernel.org; Wed, 02 Oct 2019 03:35:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58654) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFZ9q-0006c8-7y for qemu-devel@nongnu.org; Wed, 02 Oct 2019 03:34:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFZ9o-0007za-Vk for qemu-devel@nongnu.org; Wed, 02 Oct 2019 03:34:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36252) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iFZ9g-0007wf-BS; Wed, 02 Oct 2019 03:34:37 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 285363D94D; Wed, 2 Oct 2019 07:34:35 +0000 (UTC) Received: from angien.pipo.sk (unknown [10.43.2.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EEA8810018FF; Wed, 2 Oct 2019 07:34:30 +0000 (UTC) Date: Wed, 2 Oct 2019 09:34:28 +0200 From: Peter Krempa To: Max Reitz Subject: Re: bitmap migration bug with -drive while block mirror runs Message-ID: <20191002073428.GB6129@angien.pipo.sk> References: <315cff78-dcdb-a3ce-2742-da3cc9f0ca97@redhat.com> <6dd4e735-47e7-45d1-98e9-2131746d470c@redhat.com> <00f03849-18a0-bf34-b83a-98580c58826f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <00f03849-18a0-bf34-b83a-98580c58826f@redhat.com> X-PGP-Key-ID: 0xD018682B X-PGP-Key-Fingerprint: D294 FF38 A6A2 BF40 6C75 5DEF 36EC 16AC D018 682B User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 02 Oct 2019 07:34:35 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vladimir Sementsov-Ogievskiy , John Snow , qemu-devel , Qemu-block Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Oct 01, 2019 at 17:26:13 +0200, Max Reitz wrote: > On 01.10.19 16:53, Vladimir Sementsov-Ogievskiy wrote: > > 01.10.2019 17:34, Max Reitz wrote: > >> On 01.10.19 16:27, Vladimir Sementsov-Ogievskiy wrote: > >>> 01.10.2019 17:13, Max Reitz wrote: > >>>> On 01.10.19 16:00, Vladimir Sementsov-Ogievskiy wrote: > >>>>> 01.10.2019 3:09, John Snow wrote: [...] > Well, I=E2=80=99d think it should be on the one with the same node name, = but it > appears others don=E2=80=99t want a node-name-based mapping, so maybe I s= hould > just stop trying to be part of the discussion. :-) >=20 > > Still, if you don't like skipping explicit filters, I'm OK with implici= t only, it will > > fix the bug we are saying about. > >=20 > > But why you don't like creating some additional explicit filters on tar= get (prior to > > migration process) which we didn't have on source? >=20 > Because I feel like (without having too much insight into migration, I > admit) that migration is generally a process where you move from one VM > to another, but both should have the same configuration. If you want to During migrations you might want to change backends of the devices though. (E.g. reconfigure disk paths) or network connections so that the VM works on the different host. In addition some bits of migration are not symmetrical. In libvirt we use a blockdev/drive-mirror to copy over disks if you request migration with non-shared storage. The destination runs an NBD server and the source runs the blockjob to copy it over. There can't be symmetry in this case. > change the configuration, you do that before or after the migration. > (I=E2=80=99d think.)